refactor: render static page headers on the server

[Vrohs]

By submitting this PR, I confirm I have followed the Contributing Guide.

Description

Moves the static page headers out of the client components and into the server page.tsx for the two routes where that is possible, rules/approve and dashboard. Both now match what dids, rses, rules, subscriptions and suspicious-replicas already do: <header className="mb-8"> in the server component, with the interactive parts untouched below it.

Worth flagging in case it changes what is wanted here: splitting a component inside component-library would not have moved anything, since whatever a client component imports stays in the client bundle regardless of hooks. The markup has to reach the server component. Grepping the production build for each header's text:

route	build/static (client-served) before	after
/rules/approve	1 chunk	0 chunks
/dashboard	1 chunk	0 chunks

Both are still rendered into the initial HTML from the server, so this is a bundle change rather than a rendering one: these components were already server-rendered and then hydrated.

The four detail pages are not candidates and are left alone. DetailsDID, DetailsRSE, DetailsSubscription and DetailsRule head their pages with CopyableHeading, which uses navigator.clipboard and useToast and so has to stay a client component; three of the four also render fetched data that is not available at the server component. Happy to be corrected if something else was intended for those.

Checklist

• This PR closes Intertwined server and client components parts #817
• Tests cover the change, or no tests are needed
  
• Documentation is updated (link the docs PR here), or no documentation change is needed
  
• Database migrations are included, or the change touches no database schema
  
• This PR contains no breaking changes, or the breaking change is described
  in the description and the commit follows conventional commits

Notes for contributors

• Commit trailers: Please also link the issue in the commit message (see
  the Contributing Guide): use Closes: #____ on the commit that resolves
  the issue, and Issue: #____ on intermediate commits or if the issue
  should remain open.
• Reviewer: After submitting, assign a reviewer if you know who is
  appropriate for the touched components; otherwise leave it empty and one
  will be assigned.
• Stale PRs: PRs with failing tests or an unresponsive author will be
  closed promptly.

Additional notes for reviewer

Note: This OPTIONAL section is only relevant for the REVIEWER, please leave it in the PR

Reviewer template

Reviewers should copy&paste the code-block below and fill it out for APPROVED pull requests. If the PR does not meet the standards the project sets out, the reasons should be WELL EXPLAINED in a CHANGE REQUEST (The answers below do not need to be answered in that case)

• Confidence in review: I am confident in my review concerning the components this PR touches: [High 🟢, Medium 🟡 Low 🔴]
• Confidence in scope: I am confident that this fits into the scope of the project and should be included: [High 🟢, Medium 🟡, Low 🔴]
  • For Medium and Low, explain in notes why this should be included
• Quality: The approach is sound, maintainable and addresses the issue in the best way: [Agree 🟢]
• Security: This PR does NOT require increased attention in terms of security (E.g. new dependencies): [Agree 🟢, Disagree 🔴]
  • If Disagree explain in notes.
• Backwards compatibility: This PR does NOT introduce backwards compatibility breaking changes: [Agree 🟢, Disagree 🔴]
  • If Disagree explain in notes
• Testing: This PR is well tested: [Agree 🟢]
• Documentation: Relevant documentation or comments are updated or not required: [Agree 🟢]

- **Confidence in review**: High 🟢 Medium 🟡 Low 🔴
- **Confidence in scope**: High 🟢 Medium 🟡 Low 🔴
- **Quality**: Agree 🟢
- **Security**: Agree 🟢 Disagree 🔴
- **Backwards compatibility**: Agree 🟢 Disagree 🔴
- **Testing**: Agree 🟢
- **Documentation**: Agree 🟢

# Notes for merger