Add publication system: dashboard, creation flow, publication pages
SkyPress auto-created one invisible publication per user (url = /@handle)
and had no UI to manage it. Replace that with a real, user-managed system:
multiple publications, a dashboard, a create/edit flow (name, logo,
description), and publication-centric public pages.
URL model becomes handle-namespaced (Decision 0010), all resolved from the
PDS so the no-database/no-KV stance holds — no global slug registry:
/@handle author index (lists the author's SkyPress publications)
/@handle/{slug} a publication's home
/@handle/{slug}/{rkey} a document within that publication
Slugs are auto-derived from the name, de-duplicated within the writer's own
repo, and frozen into publication.url so a rename never breaks links. SkyPress
manages only publications whose url origin is its own, so a record written by
another standard.site tool (Leaflet, …) is never listed, edited, or rendered.
Deleting a publication cascades to its documents and their Bluesky posts.
Publishing now targets a chosen publication (the editor gains a selector); the
implicit ensurePublication is gone. The author index revives the paused profile
work, reading app.bsky.actor.profile straight from the PDS (no appview) for
name/bio/avatar/cover — rendered as text, never injected as HTML.
Guardrails kept: reading pages import no @wordpress JS, every PDS-derived fetch
goes through safe-fetch, and the Bluesky-post disclosure stays on publish.
Spec: docs/specs/sp10-publication-system.md. Built test-driven (records, CRUD,
publish target, cascade delete, slug rules, profile + publication resolution).