fix: gate workflow detail pages on the workflow feature flags

Follow-up from #1706 (review).

## Problem

Workflow **detail** pages are neither gated at render nor excluded from prerendering, so a flag-gated workflow has a fully reachable page.

`makeWorkflowStaticPaths` (`packages/shared/services/staticGeneration/workflow/staticPaths.ts`) emits one path per catalog workflow plus the interim ones, with no feature-flag filter — it runs at build time, where per-user flag state doesn't exist. Both sites' detail pages then render it with no gate above the view:

```tsx
// sites//pages/data/workflows/[trsId]/index.tsx

```

Unlike the four configure pages, there is no `WorkflowGate` here. So with `hyphy` off, `/data/workflows/` is prerendered and renders the workflow in full, even though it appears in no listing.

Prerendering the flag-inclusive superset is deliberate — the same pattern the organism pages use, where the superset is prerendered and gated at render (#1473). The gap is the missing render-time gate, not the prerendering itself.

## Proposed change

Wrap the detail view in `WorkflowGate` on both sites, matching the configure pages, so the superset stays prerendered and the gate decides at render.

Decide alongside it whether a gated workflow's URL should 404 or show the "workflow not found" fallback — the configure pages use the fallback today, and consistency is probably worth more than the distinction.

Depends on / pairs with #1726: until the category-level gate is resolvable from workflow identity, a `WorkflowGate` here would cover the workflow-level flags only, leaving Assembly-category workflow detail pages reachable.

## Acceptance criteria

- [ ] With a workflow-level flag off, that workflow's detail page renders the fallback on both sites.
- [ ] The flag-inclusive superset is still prerendered (no build-time flag filtering).
- [ ] Gated detail and configure URLs surface the same thing.