Add KeyResolver for transaction context to credential key mapping

[arnaugiralt]

Summary

Adds a KeyResolver abstraction that lets providers resolve credential keys (e.g., tenant IDs) from standard transaction context fields instead of requiring explicit overrides in tx.Data on every request.

• KeyResolver interface + ResolveFromContext helper with strict fallback chain: tx.Data override → resolver → error. Malformed overrides never fall through (fail-strict).
• StaticMapping built-in implementation: declarative rule table with glob patterns, specificity ranking, and fail-closed on no match. Ambiguous rules (equal specificity, overlapping patterns) are detected and warned at construction time — no per-request overhead.
• Integrated into microsoft.RefreshTokenSource — TenantID is now resolvable via KeyResolver when absent from tx.Data. Resource remains required in tx.Data (per-request concern). validTenantID regex runs regardless of source.
• Reference docs, tutorial, and onboarding guide updated.

Motivation

The Connect platform only sends explicit credential keys (like TenantID) in context data when a connector overrides them. Most requests carry only standard fields (VendorID, MarketplaceID, etc.). Without a resolver, every request must include TenantID — a requirement that doesn't match real-world usage.

Design

Follows the module's existing pattern: interface + built-in implementation, optional in Config.

Existing pattern	New parallel
TokenStore interface	KeyResolver interface
FileStore built-in impl	StaticMapping built-in impl
Config struct with optional field	KeyResolver in Config, optional

Changes from review

• Ambiguous rule detection moved to startup (cae15f2): StaticMapping now detects overlapping rule pairs at construction time using the same fieldsMayOverlap heuristic as Mux.Handle (PR feat(contrib): add reusable auth building blocks and request multiplexer #48 precedent). Per-request tie-breaking warning removed from ResolveKey — hot path is allocation-free. Disjoint literal values are recognized as non-overlapping and do not warn.

Test plan

• ResolveFromContext unit tests: present/absent/malformed values, resolver delegation, error propagation
• StaticMapping unit tests: specificity ranking, glob matching, tie-breaking, catch-all, empty key panic, no-match error
• StaticMapping overlap detection: glob overlap warns at startup, disjoint literals no warning, different specificity no warning
• Microsoft integration tests: resolver used when TenantID absent, tx.Data overrides resolver, malformed data errors with resolver configured, no resolver no data errors, resolver error propagated, path traversal rejected from resolver
• make test-race passes
• make lint passes