feat: add footer and legal pages with shared layout updates

[erinc00]

This PR delivers the full feature/web-footer-legal scope, including footer/legal page structure, layout integration, legal-page navigation behavior, and related homepage/content updates that were developed on this branch.

What’s Included

1. Footer and Layout Integration

• Added reusable footer component and integrated it into root layout.
• Added lightweight page transition wrapper in root layout.
• Updated app shell structure to align with shared semantic styling classes.

2. New Pages

Added:

• About Project
• Who We Are
• Donate
  These pages are now accessible via footer links and follow the shared layout/styling approach.

3. Legal Pages Enhancements

• Updated Privacy Policy and Terms of Service pages with shared policy page classes.
• Back navigation behavior was improved:
• Uses browser history (← Back) to return to the actual previous page.
• Includes fallback navigation to home if no history is available.

4. Homepage / CTA Refinements (as included in this branch)

• Hero slide CTA flow was updated:
• First slide links to Who We Are and About Us (About Project).
• Removed redundant secondary CTA buttons where both CTAs targeted the same route.
• Mobile-request themed slide CTA updated to Download Mobile App (placeholder # for now).

5. Content Linking Updates

• Added project wiki link on About Project page
• Added per-member wiki links on Who We Are page for all listed team members.

6. Styling

Added/updated token-compatible semantic CSS classes for:

• Footer
• Policy pages
• Project/about sections
• Team member links
• Page transition behavior

Preserved branch styling approach without broad unrelated refactors.

Dependency Note

Please merge this PR only after the Emergency Numbers PR is merged into development.

• feat: add emergency numbers flow and refine homepage hero layout #171

Closes #165

[gulcetahtasiz]

Everything looks good, nice work

[kckagancan]

Review notes

1. web/src/components/layout/PageTransition.tsx

key={pathname} forces the wrapped subtree to fully remount on every route change.

This is a real issue in the current setup because the transition is applied around the routed children from the root layout. As a result, navigation resets the wrapped tree instead of letting the App Router preserve it.

2. web/src/app/layout.tsx

PageTransition is applied too high in the tree by wrapping the entire routed children subtree.

Together with key={pathname} inside PageTransition, this defeats route subtree persistence and can reset local state on navigation. That goes against the persistence benefits of the Next.js App Router layout model.

3. web/src/components/layout/SiteFooter.tsx

The legal links hardcode ?from=home:

• /terms-of-service?from=home
• /privacy-policy?from=home

Since the footer is reusable across multiple pages, these links will claim the user came from home even when they did not. That creates false navigation context and can lead to incorrect behavior if the destination pages use this query parameter for back navigation or conditional UI.

4. web/src/components/ui/navigation/BackButton.tsx

The component uses window.history.length > 1 to decide whether to call router.back().

This is not a reliable check for whether there is a valid in-app previous page. In some cases, it can send the user back to an external page or an unrelated browser history entry instead of keeping navigation inside the app and using the fallback route.

[erinc00]

Review notes

1. web/src/components/layout/PageTransition.tsx

key={pathname} forces the wrapped subtree to fully remount on every route change.

This is a real issue in the current setup because the transition is applied around the routed children from the root layout. As a result, navigation resets the wrapped tree instead of letting the App Router preserve it.

2. web/src/app/layout.tsx

PageTransition is applied too high in the tree by wrapping the entire routed children subtree.

Together with key={pathname} inside PageTransition, this defeats route subtree persistence and can reset local state on navigation. That goes against the persistence benefits of the Next.js App Router layout model.

3. web/src/components/layout/SiteFooter.tsx

The legal links hardcode ?from=home:

• /terms-of-service?from=home
• /privacy-policy?from=home

Since the footer is reusable across multiple pages, these links will claim the user came from home even when they did not. That creates false navigation context and can lead to incorrect behavior if the destination pages use this query parameter for back navigation or conditional UI.

4. web/src/components/ui/navigation/BackButton.tsx

The component uses window.history.length > 1 to decide whether to call router.back().

This is not a reliable check for whether there is a valid in-app previous page. In some cases, it can send the user back to an external page or an unrelated browser history entry instead of keeping navigation inside the app and using the fallback route.

Implemented in 4b1b8ab, thanks for the review.

• Removed route-keyed remount behavior in PageTransition (key={pathname}).
• Stopped wrapping root layout children with PageTransition to preserve App Router subtree persistence.
• Removed hardcoded ?from=home from reusable footer legal links.
• Updated BackButton to avoid history.length checks and use a safer same-origin back behavior with fallback routing.

[kckagancan]

Looks fine now. Ready to merge