feat: add trusted tenant identity resolution for shared-router multi-tenancy

Summary

Implement the trusted tenant identity resolution layer required by shared-router multi-tenancy.

Parent roadmap: #2287 Parent issue: #2342 Related: #2286 Related code: src/semantic-router/pkg/authz, src/semantic-router/pkg/config/config.go, src/semantic-router/pkg/extproc, dashboard/backend/router/auth_routes.go

Motivation

#2342 requires tenant selection to be invisible to standard clients and derived from trusted auth. The router already has authz identity headers and providers. Multi-tenancy should build on that trusted boundary, stripping or ignoring client-supplied tenant identifiers.

Scope

Define and implement:

• tenant identity source from API key/auth layer/authz provider;
• canonical internal tenant key separate from raw user/group IDs;
• client-supplied tenant header rejection/stripping behavior;
• fail-open/fail-closed behavior;
• safe diagnostics and replay fields.

Non-goals

• Do not trust arbitrary client headers for tenancy.
• Do not store raw API keys or raw tenant secrets in replay.
• Do not mix tenant identity resolution with recipe evaluation.

Acceptance criteria

• A trusted identity source can select tenant scope before routing.
• Tenant identity is normalized and redacted in diagnostics.
• Existing single-tenant authz behavior continues to work.