**CI (#17, #28, #55)**: move `corepack enable` to run AFTER
`actions/setup-node` in all four workflows (deploy-web, deploy-docs,
lighthouse, test-web). Corepack shims are installed into whichever
Node lives on PATH at the time; running it first means setup-node
later switches to a different Node install that lacks the shims,
causing intermittent `pnpm: command not found` failures.

**Web (#34)**: registry detail page now tries both MCP manifest
layouts — flat `mcp/<id>.toml` (legacy, still the majority) and
directory-backed `mcp/<id>/MCP.toml` (new, multi-file packages) —
matching what `web/scripts/fetch-registry.ts` already accepts. The
resolved path (whichever candidate returns 200) is what the
"View on GitHub" and commit-history lookups use, so those links
always point at the file the user is actually viewing.

Extracted `pathCandidatesFor` and `fetchFirstAvailable` into
`web/src/lib/registry-raw.ts` so the list page's hover-prefetch
and the detail page's real fetch share one cache entry and one
source of truth for path layout. Dropped the redundant
`fileNameFor` field from `CATEGORY_META` — it duplicated the
same knowledge.

… pnpm

Codex comments #17, #28, #55 asked us to move `corepack enable` after
`actions/setup-node`, arguing that corepack's shims are bound to the
pre-setup-node Node install. In practice the opposite is true: the
`cache: pnpm` option on setup-node runs `pnpm --version` to compute
the cache key during setup, so pnpm MUST be on PATH before that step.
Putting corepack after setup-node fails every run with
`Unable to locate executable file: pnpm` — which is what we saw on
deploy-web, deploy-docs, lighthouse, and test-web after the previous
commit.

Modern setup-node (v6 + Node ≥22, which bundles corepack) preserves
corepack shims across the Node swap, so one `corepack enable` up
front is both necessary and sufficient. Restore the original ordering
in all four workflows and leave a comment explaining why the
Codex-suggested ordering doesn't work here.