Card heading level should be a prop (TagDetail renders section h2 followed by ProjectCard h2s)

## Context

The shared cards render a fixed heading level: `ProjectCard` renders `h2`, `PersonCard` and `HelpWantedCard` render `h3`. PR #157 worked around this on the index screens by adding sr-only `

Results

` headings above the `h3` cards rather than changing the cards, because each card is also used in a second context where its fixed level is correct.

## Problem

The fixed level is still wrong somewhere. `TagDetail` renders a section `

` ("Projects", "Help wanted", "Members") and then a list of `ProjectCard`s, each of which contributes another `h2` — so the section heading and every card title sit at the same level, and the document outline reads as a flat run of h2s instead of section → items. Any future screen that composes cards under a section heading hits the same problem.

## Proposal

Give the three cards a `headingLevel` prop (`2 | 3 | 4`, defaulting to today's level so nothing changes at existing call sites), rendered via a small `Heading` helper or `createElement(`h${level}`)`. Then `TagDetail` passes `headingLevel={3}` to `ProjectCard`, and the sr-only "Results" headings on `PeopleIndex` / `HelpWantedIndex` can be revisited (the cards could render `h2` directly there).

Related: issue #156 (CardTitle semantics) covers the design-decision side of card headings.

Deferred from `plans/a11y-mechanical.md` (PR #157).

Repérez les points d’entrée nommés ProjectCard, PersonCard, HelpWantedCard, TagDetail, PeopleIndex et HelpWantedIndex, puis lisez plans/a11y-mechanical.md et issue #156 pour le contexte des titres. Vérifiez d’abord les niveaux de titres et les sites d’appel existants ; le travail est terminé lorsque les cards acceptent les valeurs par défaut proposées, que TagDetail produit des titres allant de la section à l’élément et que le comportement des index est vérifié sans casser les utilisations existantes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.