fix(config): bind the instance-identity settings to the env vars the chart sets

pydantic-settings derives the env var from the field name, so `instance_role`
bound INSTANCE_ROLE and silently ignored the chart's STATE_HUB_INSTANCE_ROLE.
The value reached the pod and was discarded: central reported "unknown" while
its ConfigMap said "primary".

That is the same failure this workplan closes — configuration declared but
never reaching what it configures — reintroduced while building the guard
against it. Rendering the key in `helm template` was mistaken for evidence
that it bound.

Renames to state_hub_instance_role / state_hub_instance_label, matching the
existing state_hub_report_dir precedent, so the env var the chart already sets
is the one that binds.

tests/test_instance_identity.py asserts the env var *name* binds, which is the
check that would have caught this before deploy, plus the unknown default and
rejection of invalid roles.

Refs CUST-WP-0067-T03

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006

api/routers/state.py

@@ -1113,8 +1113,8 @@ async def health_check(session: AsyncSession = Depends(get_session)) -> dict:
             "status": "ok",
             "db": "connected",
             # Identity, so a caller can verify it reached the hub it meant to.
-            "instance_role": settings.instance_role,
-            "instance_label": settings.instance_label,
+            "instance_role": settings.state_hub_instance_role,
+            "instance_label": settings.state_hub_instance_label,
         }
     except Exception as exc:
         return JSONResponse(