Custom URL slugs — sim auto-claim, gathering form, link generators

S5 — Bulk slug‑map fetch returns empty in production list views fixed in 05a8463

The biggest production finding. fetchSlugMap() is called by /gallery, /events, /my-sims, /stats server components to bulk‑hydrate slug‑aware href props for client components. In production, it returned an empty map even though the alias record existed on the facilitator’s PDS.

Inspected JSON payload (before fix):

"simCreations": [
  {
    "uri":  "at://did:plc:cpoagodpqrgs4t7thi5z37uf/org.simocracy.sim/3mkt33lmhu62a",
    "href": "/sims/did%3Aplc%3Acpoagodpqrgs4t7thi5z37uf/3mkt33lmhu62a",  ← should be /sims/pm-slug-test-2026
    "name": "PM Slug Test 2026",
    ...
  }
]

Cause. lib/atproto-utils.ts → listRecordsFromPds doesn’t pass cache: "no-store" on its fetch. Next.js’s default fetch cache kept the first response forever in production builds. The first SSR request after deploy got the empty list (no aliases yet), and that empty response was served indefinitely. The forward lookup (fetchAliasBySlug → getRecordFromPds) was uncached because it’s called from an API route with force‑dynamic.

Fix shipped. Replaced the listRecordsFromPds call with a local listAllAliases helper inside lib/aliases.ts that paginates the facilitator PDS directly with cache: "no-store". Detail-page generateMetadata canonical-URL lookups now use a sibling findSlugForTargetFresh helper for the same reason.

Verified post-deploy:

$ curl -s "https://simocracy.org/stats?cb=$(date +%s)" \
    | grep -oE '"href":"[^"]+","name":"PM Slug Test 2026"'
"href":"/sims/pm-slug-test-2026","name":"PM Slug Test 2026"

$ curl -sL "https://simocracy.org/sims/did:plc:cpoag.../3mkt33lmhu62a" \
    | grep -oE '<link rel="canonical"[^>]*>'
<link rel="canonical" href="https://www.simocracy.org/sims/pm-slug-test-2026"/>

S3 — Manual slug override wedges on “Checking availability…” fixed in 05a8463

Opening “Edit Appearance” on a slug‑claimed sim shows the new Custom URL section pre‑filled with the current slug (screenshot 13). Typing a new slug (e.g. pm-slug-test-renamed-2026) triggered the debounced check, but the status never settled — it stayed on Checking availability… indefinitely (screenshot 14), even though the underlying API responded in <100 ms (verified via direct curl).

Cause. The useEffect that drives the check had [draft, currentSlug, status] in its dependency array. Setting status = "checking" inside the effect re‑fired the effect itself — the cleanup cleared the in‑flight timeout, the new effect started a fresh one, repeat forever. Classic effect‑dependency loop.

Fix shipped. Dropped status from the dependency array; replaced the “don’t run while loading” guard with a loadedRef that the load effect flips at the end. The in‑flight slug guard becomes a per‑effect‑invocation alive boolean captured in the cleanup, killing late responses cleanly. Same shape as the gathering‑form‑dialog (which already worked).

The auto‑claim path (S3’s primary purpose) was unaffected by this bug; manual rename is now functional after deploy.