fix(web): return restricted share viewers to the video after sign-in

[stefanoNELP]

Summary

Restricted /s/{videoId} pages tell the viewer to sign in, then send them to /login with no next. Google OAuth dumps them on /dashboard; they have to refresh the original tab.

Login already honors ?next= (getSafeNextPath + LoginForm). This wires PolicyDeniedView to /login?next=/s/{videoId} and adds a visible Sign in button so the CTA is not a gray word in the body copy.

email_restriction_denied stays copy-only — those viewers are already signed in.

Fixes #2192

Test plan

• Open a video with email restriction while signed out. Denied page shows Sign in.
• Sign in with Google. Land back on /s/{videoId}, not /dashboard.
• Same for a private video (This video is private).
• Signed-in user whose email fails the restriction still sees copy-only denial.

Made with Cursor

Greptile Summary

The PR adds a safe return path and visible sign-in CTA to restricted share-page denial states so anonymous viewers return to the requested video after authentication.

• Passes the current video ID into PolicyDeniedView.
• Uses /login?next=/s/{videoId} for inline and button sign-in links.
• Keeps the button hidden for signed-in viewers denied by email restrictions.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking misleading Sign in CTA for authenticated users who cannot access a private video.

The intended anonymous sign-in return flow is preserved, but reasonless private-video denials do not distinguish signed-in viewers, causing the new CTA to redirect those users back to the same denial.

Files Needing Attention: apps/web/app/s/[videoId]/page.tsx

Important Files Changed

Filename	Overview
apps/web/app/s/[videoId]/page.tsx	Adds login return-path links to policy-denied views, but the new button is also shown to already-authenticated users denied access to private videos.

Prompt To Fix All With AI

### Issue 1
apps/web/app/s/[videoId]/page.tsx:205-212
**Misleading Sign In CTA**

A signed-in user who lacks access to a private video receives a reasonless policy denial, so this condition still displays the Sign in button. Clicking it redirects the authenticated user back to the same denied video, creating a dead-end CTA.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(web): return restricted share viewer..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

Context used:

• Knowledge Base — Web application routes and components

[greptile-apps]

Misleading Sign In CTA

A signed-in user who lacks access to a private video receives a reasonless policy denial, so this condition still displays the Sign in button. Clicking it redirects the authenticated user back to the same denied video, creating a dead-end CTA.

Knowledge Base Used: Web application routes and components

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/web/app/s/[videoId]/page.tsx
Line: 205-212

Comment:
**Misleading Sign In CTA**

A signed-in user who lacks access to a private video receives a reasonless policy denial, so this condition still displays the Sign in button. Clicking it redirects the authenticated user back to the same denied video, creating a dead-end CTA.

**Knowledge Base Used:** [Web application routes and components](https://app.greptile.com/cap/-/custom-context/knowledge-base/capsoftware/cap/-/docs/web-application-routes.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.