[audit/spike] Design a permission-management systemview

[bnema]

Summary

Stored site permissions currently have no targeted management UI even though the docs already point to that gap.

Why this matters

Users who choose "Always Allow" or "Always Deny" have no focused recovery path today beyond deleting the entire local database.

Evidence

• docs/reference/permissions.md:73-78 says stored permissions currently can only be cleared by deleting the database and notes that a permission management UI is planned.
• internal/infrastructure/persistence/sqlite/permission_repo.go:23-72 already supports get/set/delete/list operations by origin.
• internal/ui/systemviews/ has history, favorites, and config views but no permissions view.

Suggested scope

Treat this as a design/spike issue first:

• define the UX for listing, deleting, and resetting permissions by origin
• define the usecase/bridge surface needed for systemviews
• decide the minimum shippable scope before adding richer editing flows

Acceptance criteria

• A concrete design/spike outcome exists (scope, API surface, open questions).
• The proposed first implementation can reset permissions without deleting unrelated user data.
• Follow-up implementation work can be split cleanly from the spike.

Audit context

• Audit date: 2026-06-10
• Audited at commit: 5eba8fd5