F4: Chat app missing CAC/PIV amr-claim enforcement — password-only accounts can read RMF conversation history

## Security Finding: F4 — CAC/PIV Enforcement Gap (Chat App)

**Severity:** High
**Source:** Winter Soldier security review of PR #828 (DEF-001 auth fix)
**Traceability:** Closes follow-on from #822 (DEF-001) · Related PR: #828
**Target Remediation Date:** 30 days from filing

---

### Summary

The MCP server correctly validates `amr` claims to enforce CAC/PIV authentication. The **Chat app does not apply the same check**, meaning a password-only Azure AD account can authenticate and access RMF conversation history without a hardware token.

For a DoD RMF product this is a material gap — CAC/PIV enforcement must be consistent across all surfaces that touch classified or controlled conversation data.

---

### Pattern to Mirror

The MCP server's existing `amr`-claim validation is the approved pattern. The Chat app's auth middleware should mirror that check:

- Inspect the `amr` claim in the validated JWT.
- Require at least one of: `ngcmfa`, `mfa` with a hardware-bound credential indicator, or the DoD-accepted PIV/CAC `amr` values.
- Reject (401) any token that does not satisfy the CAC/PIV requirement before serving RMF conversation history.

Reference the MCP server implementation for the exact claim values and rejection logic to replicate.

---

### Acceptance Criteria

- [ ] Chat app middleware reads and validates the `amr` claim on every authenticated request.
- [ ] Password-only tokens (no CAC/PIV `amr` value) are rejected with HTTP 401.
- [ ] Parity test added: same token rejected by Chat app and MCP server.
- [ ] No regression on legitimate CAC/PIV-authenticated flows.

---

### References

- DEF-001 record: #822
- Auth fix PR: #828
- MCP server amr-claim check (pattern to mirror)

> **This issue is non-blocking for merging PR #828 but must be resolved within 30 days of this filing.**

Start by locating the MCP server's existing amr-claim validation and the Chat app authentication middleware. Compare their handling of validated JWTs, then add the requested parity test for password-only and CAC/PIV-authenticated tokens. Done means invalid tokens receive HTTP 401 while legitimate CAC/PIV flows continue to work.

Written by the indexing model from the issue text.