Rename /my-applications To /applications

[b-at-neu]

Goal

Rename the applicant's own application list from /my-applications to /applications, completing the scheme decided in #625 and removing the my- prefix entirely.

Blocked by the /manage/applications move. /applications has to be vacated before it can be claimed.

Why this is worth doing

The my- prefix is currently inconsistent with itself: /my-applications means "mine as a user", while /my-positions means "positions I administer". Once management lives under /manage/*, the prefix has no remaining job — the bare noun is unambiguous, because the managerial view has moved.

End state:

Audience	Routes
Applicant / public	/positions, /applications
Manager	/manage/positions, /manage/applications
Admin	/users, /global-questions

Do this before #548 ships

Sent email is immutable. #548 adds applicant emails whose call to action links to the applicant's own application. Once those are delivered carrying /my-applications/[id], the links are dead the moment this rename lands — and there is no way to fix an email already in someone's inbox.

Both of #548's blockers are resolved (#547 merged, #399 closed), so it can start at any time. Either this lands first, or accept permanently broken links in already-delivered mail.

Scope

1. Move the routes.

app/(main)/(auth)/my-applications/page.tsx      → app/(main)/(auth)/applications/page.tsx
app/(main)/(auth)/my-applications/[id]/page.tsx → app/(main)/(auth)/applications/[id]/page.tsx

loading.tsx moves with each page, same width tier.

2. Confirm /applications is genuinely free. #629 leaves it as a dead route with no redirect, so this should be a clean claim. Verify nothing answers there before adding the new pages — a leftover redirect would bounce every applicant to the manager queue and 404 them, since they aren't managers.

3. Re-audit the path literals. The same ~40 occurrences and 18 revalidatePath calls come back into play. After this change both /applications and /manage/applications exist, so a wrong literal is valid and silent — it revalidates or links to the wrong audience's page with no error anywhere. Classify each one; don't pattern-replace.

4. Keep the nav label. The route becomes /applications, but the sidebar entry should still read "My Applications" — the label is what tells an applicant it's theirs, and the manage group has an "Applications" entry of its own. Route and label diverging is correct here.

5. Update login redirect handling. Check safeRedirectTo / withRedirectTo and anything with a hardcoded post-sign-in destination.

6. No redirect from /my-applications. No bookmarks exist to preserve, so let it 404.

Non-goals

• No change to what either page does.
• No change to /positions, /users or /global-questions.
• No change to application scoping or permissions.

Acceptance criteria

• The applicant's own list and detail page are served from /applications.
• /my-applications 404s.
• Verified as an applicant, not as an admin — an admin follows a stray redirect successfully and would see nothing wrong.
• The manager queue at /manage/applications still works and is unaffected.
• The nav entry still reads "My Applications" and highlights on both pages.
• All 18 revalidatePath calls verified against their intended audience.
• Any email templates or getBaseUrl-derived links point at the new path.
• docs/WORKFLOWS.md AP-10 through AP-14 updated — they all name /my-applications.
• npm run prettier:check, eslint:check, tsc:check, test all pass.