feat: expose BYOK provider-key storage through the public /v1 API

[man4ish]

Summary

Paired with omnibioai-auth's registry PR -- finishes exposing M14's BYOK provider-key storage through the public API surface.

• PUT/GET/DELETE /v1/provider-keys(/{provider}) proxy into omnibioai-auth's own PUT/GET/DELETE /orgs/{org_id}/provider-keys(/{provider}) -- the exact same forwarded-bearer-token pattern GET /v1/usage already uses for omnibioai-billing (new SERVICE_MAP["auth"]/SERVICE_PERMISSION_MAP["auth"]/V1_SERVICE_MAP["provider-keys"] entries, mirroring the "billing" entry precisely).
• Storage only -- not provider routing or token metering (the rest of design-audit gap PR12: Enterprise IAM/RBAC end-to-end validation and hardening #4), and never a billable call. Still rate-limited like every other /v1 route.
• Error mapping: auth-service's 403 (not manage_org) -> forbidden, 404 (no key configured for that provider) -> not_found, 5xx (e.g. CONFIG_ENCRYPTION_KEY unset) -> upstream_error.
• The real authorization decision stays manage_org, enforced live at the destination -- this gateway adds no new access-control logic of its own, same layered "coarse gate + service-level independent, finer check" posture router.py's own comments already establish for every other SERVICE_MAP entry.

Test plan

• pytest tests/test_v1_literature.py -- 71 passed (62 existing + 9 new: org-requirement, successful PUT/GET/DELETE forwarding with correct URLs/methods/bodies, 403/404/5xx error mapping, non-JSON body rejection, rate limiting)
• Full repo suite -- 393 passed

🤖 Generated with Claude Code