fix(auth): enforce role permissions on REST storage and settings mutations #60

Confirmed finding

With AUTH_ENABLED=true, a valid viewer API key can upload and delete managed files and write administrative settings through REST. Authentication is enforced, but these endpoints do not enforce the advertised role hierarchy.

Tested revision: 41ec093a745f1c0277893dc8f758b96b216c970f, isolated SQLite + embedded Qdrant deployment. All inputs were synthetic.

Reproduction

1. Bootstrap an admin API key and issue a key with role=viewer.
2. With the viewer key, POST /admin/api/storage/upload containing a harmless text file.
3. DELETE that fixture through /admin/api/storage/file?path=viewer-write.txt.
4. Read the current auto-sync interval and POST the same value to /admin/api/settings/auto-sync.

All three writes returned HTTP 200, not 403. Upload indexed the fixture and delete removed it. In contrast, the same viewer correctly received 403 from /admin/api/auth/keys, and anonymous requests received 401.

Relevant code

• Storage REST handlers import role helpers but do not use them to guard these mutations.
• Settings handlers similarly lack per-operation role dependencies.
• AuthMiddleware validates the token; that alone does not authorize mutations.

Expected outcome

• Apply explicit least-privilege role policies to REST operations, consistent with the MCP role contract: viewers read, editors perform permitted content mutations, admins manage configuration/credentials/keys.
• Validate the intended policy across repository/path/storage/settings endpoints rather than fixing only the three demonstrated routes.
• Reject unauthorized operations before filesystem, vector-store, configuration, or relational side effects.
• Add role-matrix regression tests including anonymous/invalid/revoked keys, viewer denials, editor content writes, and admin-only configuration.

No claim of a complete security audit is made; this records the reproduced role-policy failures.