fix(health): report configured application version

/health read the APP_VERSION environment variable directly, but
docker-compose passes App__Version, which binds to the App:Version
configuration key. The variable under that name never existed in the
container, so the endpoint always reported "unknown".

Read App:Version through IConfiguration, the approach AdminSystemController
already used for the same value. The resolution rule (configured version,
else assembly version) moves to a shared BuildMetadata helper rather than
being written twice; AdminSystemController now calls it, so the admin page
and /health cannot drift apart.

Local development is unaffected: nothing sets App:Version there, and the
assembly-version fallback still applies.

Tests pin the configuration KEY, not just the behaviour, including that an
App__Version environment variable binds to App:Version. The original bug
failed silently, so a behavioural test alone would not have caught it.

Verified against a running backend: App__Version=9.9.9-test reports
9.9.9-test; unset reports the assembly version rather than "unknown".

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

deploy/first-production-deployment.md

@@ -144,7 +144,12 @@ upstream cannot be resolved.
 ```bash
 # Health endpoint — anonymous, does not touch the database
 curl -fsS https://<host>/health
-# expect: {"status":"ok","version":"..."}
+# expect: {"status":"ok","version":"<the APP_VERSION you deployed>"}
+#
+# The version comes from App:Version, which compose passes as App__Version from APP_VERSION.
+# CI sets it to the workflow run number. A version of "1.0.0.0" (the assembly fallback) means
+# APP_VERSION did not reach the container — harmless in itself, but it tells you the build
+# metadata is not flowing, so the admin system page will be vague about what is deployed.
 
 # Auth still enforced (this is the check that proves the API is not open)
 curl -s -o /dev/null -w '%{http_code}\n' https://<host>/api/jobapplications