[Sycun]

After a one-click update, the browser can stay on the old page if it misses the final progress response. With automatically generated HTTPS certificates, restarting the server also used to change the certificate, so Chrome could reject the request that checks whether the new process is ready.

The update page now starts checking when the server accepts the job. It identifies the replacement by the activation ID and checks the running Git revision when the target is known. The settings page shows the running build revision alongside the checkout revision.

For local HTTPS with tls_auto_self_sign, the server saves the certificate and private key under data/tls/ and reuses them on restart. The first upgrade from an in-memory certificate creates a new certificate, so Chrome may still show a warning on that transition.

Validation

• On this branch: 337 frontend tests, go build ./..., the self-update and authentication Go race tests, and shell syntax checks passed.
• On Kali, a real update reproduced the Chrome certificate error after the process switched. The existing administrator session was still valid after reconnecting.
• In an isolated Chrome HTTPS update with the certificate fix, the certificate fingerprint stayed the same, the new build activated, and the page automatically returned to the update console with the original session.