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/app/main.py

@@ -1,3 +1,4 @@
+import os
 import asyncio
 from contextlib import asynccontextmanager
 from fastapi import FastAPI, Depends
@@ -77,12 +78,33 @@ async def lifespan(app: FastAPI):
 
 app = FastAPI(title="DRB C2 Core", lifespan=lifespan)
 
+# "*" plus allow_credentials=True is not the permissive-but-harmless setting it
+# looks like. Starlette does not refuse the combination -- it reflects the
+# caller's Origin back and still sends Access-Control-Allow-Credentials: true,
+# so the effective policy becomes "any origin, with credentials", the opposite
+# of what a wildcard normally means. Rather than trust every deployment to
+# remember to override CORS_ORIGINS, make the dangerous pair unrepresentable.
+def cors_allows_credentials(origins: list[str]) -> bool:
+    """False when any entry is a wildcard. Extracted so it can be tested
+    without re-importing this module, which drags in every router."""
+    return "*" not in origins
+
+
+_cors_is_wildcard = not cors_allows_credentials(settings.cors_origins)
+if _cors_is_wildcard:
+    logger.error(
+        "CORS_ORIGINS is '*', so credentialed cross-origin requests are being "
+        "DISABLED to avoid reflecting every caller's origin back with "
+        "Access-Control-Allow-Credentials. Set CORS_ORIGINS to your frontend "
+        "origin(s) in production, e.g. [\"https://app.example.com\"]."
+    )
+
 app.add_middleware(
     CORSMiddleware,
     allow_origins=settings.cors_origins,
     allow_methods=["*"],
     allow_headers=["*"],
-    allow_credentials=True,
+    allow_credentials=not _cors_is_wildcard,
 )
 
 app.include_router(nodes.router,     dependencies=[Depends(require_service_or_firebase_token)])
@@ -118,9 +140,21 @@ app.include_router(media.router)
 # against a future /internal/* route being added and forgotten there.
 
 
+# Read straight from the environment rather than through Settings: this is a
+# build stamp baked in by the Dockerfile, not configuration anyone sets or
+# tunes, and keeping it out of Settings avoids implying it can be changed.
+_GIT_SHA = os.getenv("GIT_SHA", "unknown")
+
+
 @app.get("/health")
 async def health():
-    return {"ok": True, "mqtt_connected": mqtt_handler.is_connected}
+    return {
+        "ok": True,
+        "mqtt_connected": mqtt_handler.is_connected,
+        # CI asserts this equals the commit it just deployed. Without it a
+        # deploy can "succeed" while the previous container is still serving.
+        "git_sha": _GIT_SHA,
+    }
 
 
 # Deliberately unauthenticated, same as /health above: the CI deploy step