feat(rbac): add GET /Permissions capability contract

[KinshukSS2]

Summary

Implements GET /Permissions to provide a stable backend capability contract for role-aware frontend rendering.

What Changed

• Added new read endpoint for /Permissions
• Wired router into v1 API
• Added strict Pydantic response model enforcement (extra=forbid)
• Added safe auth identity handling (401 on malformed/missing identity)
• Added policy lookup using username + role + public
• Added ALL -> read/create/update/delete command mapping
• Added tests for admin/non-admin/auth-failure, malformed identity, and role-membership lookup

Why

This is required by the RBAC proposal so frontend behavior is derived from backend truth instead of hardcoded role assumptions.

API Contract

• GET /Permissions
• 200: { username, role, permissions }
• 401: unauthorized/invalid token
• 400: backend/query failures

Validation

• pytest api/tests/test_permissions_endpoint.py -q passed (7 passed)
• Admin response path tested
• Non-admin mapping path tested
• Auth failure path tested
• ALL command mapping tested
• Malformed identity handling tested
• pytest api/tests -q has one unrelated existing failure in api/tests/test_oauth_connection_leak.py

Scope Notes

No DB migration and no frontend changes in this PR.
This PR currently represents policy-derived capability intent and does not attempt full DB effective privilege computation (GRANT/REVOKE + RLS).

fix #146

[KinshukSS2]

@danistrigaro @ClaudioPrimerano @massimiliano-cannata

For GET /Permissions, should the capability contract represent:

1.policy/RLS-derived intent (pg_policies), or
2.full effective DB privileges (GRANT/REVOKE + RLS)?

current PR implements option (1): strict schema contract + auth hardening + policy-derived capability mapping.
if you expect option (2), I can extend it in a follow-up.