Allow JWTs without token_use or full_name claims

[lucarlig]

Problem

Follow-up to #51. The dataplane still rejects otherwise valid JWTs when the token has no token_use claim or when the user object has no full_name field. ContextForge control-plane admin tokens (e.g. the ones minted by the upstream live-gateway compliance harness) carry neither, so every gateway_virtual protocol-compliance row still fails with 401 against the split stack even after #51. Verified by claim-stripping against a live deployment: removing either claim from an otherwise accepted token flips the response from 200 to 401, while username and nbf are already optional.

Summary

• make ContextForgeClaims.token_use optional
• make User.full_name optional
• preserve missing values as None, mirroring the Allow JWTs without scopes claims #51 scopes handling
• add auth-layer regression coverage for a JWT missing both claims

Validation

• cargo test -p contextforge-gateway-rs-lib (31 passed, includes new regression test)
• cargo fmt --check (no new diffs; pre-existing nightly-only drift untouched)
• cargo clippy --workspace --all-targets -- -D warnings
• live check: control-plane admin token without token_use/full_name returns 401 on current 0.1.0; same token accepted after making these claims optional

[lucarlig]

E2E verification against the live split stack (control plane at IBM/mcp-context-forge main + PR #5482 branch, dataplane image built from this branch):

• The upstream compliance-harness admin token (no token_use, no user.full_name) previously got 401 on published 0.1.0; with this branch it gets 200 and negotiates an MCP session.
• tests/live_gateway/protocol_compliance gateway target lane went from 4 failed + 14 errors (all 18 gateway_virtual-http rows rejected at auth) to 2 failed, 23 passed, 0 errors.
• The two remaining gateway_virtual failures are unrelated to auth: sessions establish, the dataplane fetches 136 tools from the backend (list_tools: backend … completed (136 items)), but the response to the client is filtered to 0 tools — an allowed_tool_names name-mapping issue for runtime-registered backends, which I'll track separately.