fix(§22.4a): scope RFCView entry-detail fetch to its collection (v0.52.1)

The §9 deployed-environment E2E harness (0.52.0), run against a PPE host
with per-collection-isolated content, surfaced a latent multi-collection
bug: RFCView computed the collection id from the route but called
getRFC(pid, slug) without it, so a named-collection entry was always
fetched via the project default-collection route — which 404s for an entry
that exists only in a named collection ("Error: Not found"; metadata panel
absent). Local/Tier-1 stacks masked it (same slug also reachable via the
default collection). Thread cid through all three getRFC call sites; re-run
the load effect on collection change.

Harness/test-infra (not in the deployed artifact):
- e2e: pre-record cookie consent via addInitScript (lib/fixtures.js) so the
  bottom-fixed consent banner can't intercept catalog row-select clicks on
  the slower deployed edge.
- testing/seed-ppe.sh: fail loudly on any non-2xx Gitea response (a
  swallowed 403 org-repo create had reached the deploy as a 502).
- testing/ppe-deploy-and-test.sh: seed via the Keychain admin token
  (write:organization needed to create the PPE repos); store the E2E secret
  newline-free; read EXPECT_VERSION from VERSION.

Patch bump 0.52.0 → 0.52.1; CHANGELOG updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -23,6 +23,32 @@ skip versions are the composition of each intervening adjacent
 release's steps in order — no A-to-B path is pre-computed beyond
 that.
 
+## 0.52.1 — 2026-06-08
+
+**Patch — collection-scoped entry-detail fetch fix (no operator action
+required).**
+
+Caught by the §9 deployed-environment E2E harness (0.52.0) running against
+a PPE host whose content is cleanly isolated per collection:
+
+- **Entry detail in a named collection 404'd ("Error: Not found") and its
+  metadata panel never rendered.** `RFCView` computed the collection id
+  from the route but called `getRFC(pid, slug)` without it, so an entry was
+  always fetched via the project's *default*-collection route
+  (`/api/projects/<pid>/rfcs/<slug>`). For an entry that lives only in a
+  named collection that route 404s. The bug was latent since the
+  multi-collection work — local/Tier-1 stacks masked it because the same
+  slug was also reachable through the default collection; a deployment with
+  per-collection-isolated content surfaces it. Fixed: all three `getRFC`
+  call sites in `RFCView` now pass the collection id (and the load effect
+  re-runs on collection change).
+
+Test-only (not in the deployed artifact): the deployed-env E2E harness now
+pre-records cookie consent via `addInitScript` so the bottom-fixed consent
+banner can't intercept catalog row-select clicks on the slower deployed
+edge, and `testing/seed-ppe.sh` fails loudly on any non-2xx Gitea response
+(a swallowed 403 had let a missing-repo seed reach the deploy as a 502).
+
 ## 0.52.0 — 2026-06-07
 
 **Minor — deployed-environment E2E harness (new opt-in test-auth surface;