fix(comments): require canView access before posting a comment

[richiemcilroy]

Closes #1982.

Problem

The newComment server action inserted a comment for any authenticated user on any caller-supplied videoId, with no check that the caller can view the video. Any authenticated user could inject comments, replies, and reactions into other users' private videos (IDOR).

Fix

Gate the insert on the existing view policy, following the exact pattern used in get-transcript.ts / get-status.ts: fetch the video id inside an Effect.gen, run it through Policy.withPublicPolicy(videosPolicy.canView(videoId)), and throw "Video not found" when the policy denies or the row does not exist. The id-only select doubles as an existence check, since canView returns true for nonexistent videos by design.

Denial is reported as "Video not found" rather than "Forbidden" so the endpoint does not become an existence oracle for private videos.

Verification

• Every currently-working comment flow maps to a canView grant path: owner, org/space share, public video, password-protected (the verified x-cap-password cookie is attached by CookiePasswordAttachmentLive in the shared runtime), and email-restricted shares. Anonymous comments were never a working flow (the action already required auth).
• All other comment/reaction write paths (mobile, v1 agent API, delete routes) already enforce view access or ownership; this action was the only unguarded write.
• Scoped biome check passes.

Note: denied comments fail silently in the UI after an optimistic insert, which matches the pre-existing failure UX of this action. A sibling low-severity leak (per-day comment counts via dashboard analytics capId) was found during review and will be filed as a follow-up; it is out of scope here.

Greptile Summary

The PR closes the comment-posting IDOR by requiring the authenticated caller to pass the existing video view policy and by verifying that the referenced video exists before insertion.

• Adds the shared VideosPolicy.canView authorization gate to newComment.
• Preserves non-disclosure behavior by reporting denied and nonexistent videos as "Video not found".
• Uses the shared Effect runtime so owner, organization, space, email-restricted, and password-authorized access contexts remain available.

Confidence Score: 5/5

The PR appears safe to merge and closes the unauthorized private-video comment path without breaking established access flows.

The new gate uses the repository's established optional-auth and password-aware Effect runtime pattern, denies callers who cannot view the video, and separately rejects nonexistent video IDs before insertion.

Important Files Changed

Filename	Overview
apps/web/actions/videos/new-comment.ts	Adds a policy-backed existence and view-access check before comment insertion; no actionable regression was identified.

_{Reviews (1): Last reviewed commit: "address review: cap existence check with..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Web App (apps/web)

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.