Make a failed deploy impossible to miss, and a wildcard CORS harmless

Two unrelated-looking problems with the same shape: a dangerous state that
looked fine from the outside.

DEPLOY (server-26#21). The Deploy job failed on fifteen consecutive pushes
between 2026-08-18 and 08-20 and nobody noticed for two days, because the
build job was green and a red run is only visible to someone who opens Gitea.
Production served 08-18 code the whole time -- including the entire frontend
redesign, chunks 2 through 8. Three changes:

  * The health check now asserts WHICH build answered, not just that something
    did. CI bakes the commit into the image (Dockerfile ARG/ENV GIT_SHA) and
    /health reports it, so a deploy that "succeeds" while the previous
    container keeps running now fails. Liveness alone could never have caught
    this.
  * The image pull retries once after a prune. The actual failure was
    containerd unable to extract a layer -- "failed to Lchown ... no such file
    or directory" -- a corrupted entry in the snapshot store, which a prune
    clears. A second failure after pruning is a real problem (check the VM's
    disk) and still stops the deploy.
  * A notify-failure job POSTs to DEPLOY_ALERT_WEBHOOK when anything in the
    workflow fails. Unset means skip quietly, not fail.

CORS (server-26#20). allow_origins=["*"] with allow_credentials=True is not
the permissive-but-harmless setting it reads as. Starlette does not reject the
pair -- it reflects the caller's Origin back and still sends
Access-Control-Allow-Credentials: true, so the effective policy is "any
origin, WITH credentials", the opposite of what a wildcard normally means.

Rather than trust every deployment to remember CORS_ORIGINS, the pair is now
unrepresentable: a wildcard forces allow_credentials off and logs an ERROR
naming the variable to set. Correctly configured deployments that name their
origins are unaffected and keep credentialed requests.

Severity honestly: low today. c2-core is bearer-auth, and browsers do not
attach bearer tokens cross-origin the way they attach cookies. This is a
misconfiguration waiting for the day something starts trusting a cookie.

Also adds firebase_admin.auth.UserRecord and the list/update/create/delete_user
names to the conftest stub. routers/users.py annotates with UserRecord at
import time, so without it importing app.main failed at collection -- which is
why nothing had ever tested anything wired at app level, CORS included.

Tests: 5 new in test_cors_policy.py, covering the pure policy function, the
middleware actually mounted on the app (so re-hardcoding allow_credentials=True
fails here), and the presence of the build stamp.

Closes logan/server-26#20
Closes logan/server-26#21

drb-c2-core/tests/test_cors_policy.py

@@ -0,0 +1,53 @@
+"""
+CORS must never end up as "any origin, WITH credentials".
+
+Starlette does not reject `allow_origins=["*"]` combined with
+`allow_credentials=True`. It reflects the caller's Origin back in
+Access-Control-Allow-Origin and still sends
+Access-Control-Allow-Credentials: true, so the effective policy is the
+opposite of what a wildcard usually means. main.py defuses that by turning
+credentials off whenever it sees a wildcard; these tests hold it to that.
+
+The policy lives in a pure function so it can be exercised directly --
+reloading app.main to vary settings drags every router back through import
+and is not worth the fragility.
+"""
+from starlette.middleware.cors import CORSMiddleware
+
+from app.config import settings
+from app.main import app, cors_allows_credentials
+
+
+def test_wildcard_alone_disables_credentials():
+    assert cors_allows_credentials(["*"]) is False
+
+
+def test_wildcard_among_real_origins_still_disables_credentials():
+    # A list that merely CONTAINS "*" is as permissive as ["*"] alone --
+    # Starlette treats any wildcard entry as allow-all.
+    assert cors_allows_credentials(["https://app.example.com", "*"]) is False
+
+
+def test_named_origins_keep_credentials():
+    # Naming your origins is how you ask for credentialed requests, so a
+    # correctly configured deployment must not be penalised.
+    assert cors_allows_credentials(["https://app.example.com"]) is True
+    assert cors_allows_credentials([]) is True
+
+
+def test_the_app_actually_mounted_that_policy():
+    """Guards the wiring, not just the helper: a future edit to main.py that
+    hardcodes allow_credentials=True again fails here."""
+    opts = next(
+        (mw.kwargs for mw in app.user_middleware if mw.cls is CORSMiddleware), None
+    )
+    assert opts is not None, "CORSMiddleware is not mounted at all"
+    assert opts["allow_credentials"] is cors_allows_credentials(settings.cors_origins)
+
+
+def test_health_exposes_a_build_stamp():
+    """CI compares this against the commit it just deployed; a deploy that
+    leaves the previous container running is otherwise invisible."""
+    from app.main import _GIT_SHA
+
+    assert isinstance(_GIT_SHA, str) and _GIT_SHA