fix(auth): issue a Secure session cookie under the __Host- prefix

A cookie named healthlog_session can be set by any host under the same
registrable domain, so a page on a sibling subdomain could plant a session of
its choosing in a visitor's browser. Wherever the session cookie is Secure it
is now issued as __Host-healthlog_session, which a browser accepts only from
this exact host. Plain-HTTP installs, which cannot hold a __Host- cookie,
keep the old name.

Nobody is signed out: the old name is still read after the new one, a
session found under it is re-issued under the new name and the old cookie
expired, and a browser holding the new cookie is never answered from the old
one. Every reader and writer goes through one module, which the proxy, the
native-caller check, the native handoff and the OIDC callback use; the
session-surface guard follows the new reader.

docs/ops/measurement-maintenance.md

@@ -107,10 +107,12 @@ In the admin area, or with a signed-in admin session:
 ```sh
 curl -X POST https://<your-instance>/api/admin/maintenance/measurements \
   -H 'content-type: application/json' \
-  --cookie 'healthlog_session=<session>' \
+  --cookie '__Host-healthlog_session=<session>' \
   -d '{"vacuum": true, "reindex": true}'
 ```
 
+On a plain-HTTP install the cookie is named `healthlog_session`.
+
 The answer is `202` with `{ "enqueued": true }`, or `enqueued: false` when a
 run is already queued or running. A Bearer token is refused: the route is
 cookie-only, like every admin route. Without a background worker the route