Your fresh install working is the useful data point - this is something about that specific server, not the pinboard code.
Here's what's actually happening: all web UI settings live in a single properties file on the machine running the web UI, under the servlet container's work directory, named nxmc.preferences.<uuid>. The uuid comes from a cookie called nxmcStoreId in your browser. If that cookie doesn't come back on the next login, the web UI generates a new uuid and opens an empty file - and the old one stays on disk with all your settings still in it. Pinboard, the "Show server clock" checkbox and column widths all live in that one file, which is why they go together.
Three things to check, and they split the problem cleanly:
How many contexts are deployed. Look at /var/lib/tomcat10/work/Catalina/localhost/ - if more than one nxmc context is there (nxmc and nxmc-6.2.4, say), each has its own state directory, and the files you find may belong to a context you are no longer using. The web UI logs a line "State directory:" at every startup naming the one actually in use.
Whether a new file appears per login. List the state directory, log in again, list it again. A new nxmc.preferences.<uuid> each time means the cookie is not coming back. The same file with a new timestamp means it is, and the problem is elsewhere.
The cookie itself. Browser dev tools, Application - Cookies, look for nxmcStoreId. It is set with a 90 day lifetime, so it should survive a logout. If your nginx config caches or strips Set-Cookie on the proxied responses, it won't.
If you already have a file there containing pinboard$<number> entries, that settles most of it on its own: saving works, and the session that comes up empty is reading a different file.
The web UI log goes to catalina.out on a Tomcat install - grep it for "State directory", "local preferences" and "Invalid store ID". (-Dnxmc.logfile is only set in our Jetty instructions, so on Tomcat everything lands in the console log.)
Note: even once this works, that directory is Tomcat's per-context work directory and it is cleared on war redeploy. So web UI settings are lost on every web UI upgrade by design - that is likely part of what you saw across the three version upgrades.
