Add an authorization/IDOR test pass on sharing and visibility

[ALeonard9]

Story

As a maintainer, I want an authorization/IDOR-focused test pass against the sharing, visibility, tiers, friends, and follows logic, so a permission bug that lets one user read or modify another user's private data gets caught before it reaches a real user, not after.

Acceptance Criteria

• Test pass covers app/router/v1/router_visibility.py, router_friends.py, router_follows.py, and their backing services (app/services/visibility.py, friendships.py, follows.py).
• For each tier/visibility level (public, friends-only, private — whatever the current model defines), confirm a user who shouldn't have access is actually denied it, not just that a user who should have access gets it. Existing tests likely already cover the happy path; this issue is specifically about the negative/adversarial case.
• Cover direct object reference attempts: requesting another user's private shelf, friend-request, or follow data by guessing/incrementing an ID or handle rather than going through an authorized relationship.
• Cover the friend-request and follow-request state machine for authorization holes (e.g. accepting/rejecting a request that isn't addressed to you, seeing pending requests that aren't yours).
• This is a manual/exploratory test-writing pass, not a scanner integration — distinct from the existing automated security.yml pipeline (gitleaks + semgrep + trivy), which does secrets/dependency/SAST scanning and has no visibility into this kind of business-logic authorization bug.

Context

Filed from a testing audit (2026-08-03) requested via Todoist task 6h9V22J3qhjH6CJW. Prompted directly by the recent sharing/visibility rework (9474b2a "Rebuild sharing and visibility: tiers, friends, follows (#272) (#283)") and the newer friend-request notification work (d04a0e3, #282) — this is exactly the shape of feature (per-user private data exposed through relationships/handles) where authorization bugs are both easy to introduce and high-impact, and static scanning can't catch them since the code runs correctly, it just runs for the wrong caller.

Estimate

• Recommended model: Opus 4.8 — adversarial/security-reasoning task benefits from a stronger model actively trying to break the authorization model, not just pattern-matching test cases
• Human effort: M — one review pass on the test cases chosen, and judgment calls on which findings (if any) are real bugs vs. acceptable by design