rename: civiccore -> townlight-core (CivicSuite -> Townlight rebrand)

[scottconverse]

Summary

Renames this repo's Python packaging from the pre-rename civiccore brand to the approved townlight-core / townlight_core scheme, following the CivicSuite org and repo move to the townlight org on 2026-08-12.

• civiccore/ -> townlight_core/; civiccore-ui/ -> townlight-core-ui/ (kept kebab-case — it's a frontend CSS/HTML asset directory, not a Python package, and has no .py files).
• pyproject.toml: name = "civiccore" -> "townlight-core"; description/authors/keywords/[project.urls] updated to Townlight.
• All internal imports and references in code, tests, CI workflows (ci.yml, release.yml, cleanroom.yml), the cleanroom Dockerfile, and cleanroom/orchestrator scripts updated to the new package path.
• README.md, USER-MANUAL.md/.txt, docs/index.html rebranded in prose. USER-MANUAL.docx/.pdf regenerated via scripts/gen-user-manual.py so all four manual formats stay consistent.
• CHANGELOG.md: added a new [Unreleased] entry describing the rename (including the "intentionally not renamed" list below); pre-existing dated entries are untouched.

Intentionally left unchanged (and why)

Persisted database state — renaming these would silently break every already-deployed consuming module's database, since this package's migrations run inside the same Postgres database as consumer apps, before their own migrations:

• The Alembic version table name alembic_version_civiccore (townlight_core/migrations/alembic.ini, env.py, runner.py).
• The three shipped migration revision IDs and their files (civiccore_0001_baseline_v1.py, civiccore_0002_llm.py, civiccore_0003_local_task_queue.py) — only their from civiccore...import lines were updated so they still execute; revision/down_revision strings, table names, and column defaults are untouched (Alembic migrations are immutable once shipped, independent of branding).
• The civiccore_local_tasks table name (townlight_core/platform/task_queue.py).
• The consumer_app='civiccore' / CIVICCORE_DEFAULT_APP prompt-template DB default (townlight_core/llm/templates/{resolver,models,schemas,overrides,exceptions}.py) — this literal string is already stored in every consuming module's prompt_templates rows.

Cryptographically/historically pinned identity:

• townlight_core/release_provenance.py's default --repo value and User-Agent string, plus the pinned CivicSuite/civiccore, civiccore-<version>-py3-none-any.whl, and v0.22.1 references in scripts/cleanroom/townlight-core-cleanroom-runner.sh and tests/test_release_provenance.py. These match the real, already-published release history — the Sigstore certificate identity embedded in those existing signatures literally says CivicSuite/civiccore, so verifying them against a renamed identity would fail. Only the source repo clone URL (a separate concept from "which release is being verified") was updated to townlight/core.

Historical/evidence content, matching the task's stated policy: docs/audits/, docs/ops/, docs/evidence/, docs/qa/, docs/adr/, sprint-phase2-evidence/, tests/fixtures/release_provenance/, dated diagram/screenshot artifacts (docs/diagrams/civiccore-extraction-map.*, docs/browser-qa-*), docs/release-recovery-status.md, docs/github-discussions-seed.md, and pre-existing CHANGELOG entries.

Verifier-pinned strings: civiccore/catalog, exemptions, scaffold placeholder __init__.py docstrings are pinned verbatim (including the phrase "versioned CivicCore release artifact") by tests/test_placeholder_adrs.py against the frozen ADR docs — left unchanged rather than partially edited into an inconsistent state. scripts/check-tier1-ledger.py is pinned by tests/test_tier1_retrofit_ledger.py and validates a frozen ledger doc whose own "repo" field says CivicSuite/civiccore — left unchanged.

docs/SUPERVISOR.md was also left untouched: it's a self-described point-in-time snapshot card (references v0.2.0 and specific line numbers already stale relative to v1.2.1), not a currently-accurate living doc, so a branding-only edit would leave it still wrong.

Also renamed (breaking change, but not a data-corruption risk)

• CIVICCORE_* env vars (CIVICCORE_SUITE_SESSION_SECRET, CIVICCORE_SUITE_SESSION_REVOCATION_FILE, CIVICCORE_TASK_HANDLER_MODULES) -> TOWNLIGHT_CORE_*.
• The civiccore_version / civiccore_min_version / civiccore_locked manifest contract fields (townlight_core/connectors/manifest.py, townlight_core/platform/modules.py) -> townlight_core_version / etc.
• CI/cleanroom naming conventions: freeze tag pattern civiccore-*-freeze -> townlight-core-*-freeze, build artifact name civiccore-dist -> townlight-core-dist, docker labels civicsuite-cleanroom=1 -> townlight-cleanroom=1.

None of these are persisted database state — they're env var names, JSON/manifest contract field names, and CI-internal naming — so renaming them doesn't corrupt anything that already exists. They do mean any future release (and any consumer that upgrades to it) needs to adopt the new names; this is called out in the CHANGELOG [Unreleased] entry.

Sibling-repo dependency mechanism (investigation, no other repos modified)

Consumers pin civiccore via a PEP 508 direct-reference dependency to a GitHub Release wheel asset, not a git URL and not vendoring:

"civiccore @ https://github.com/CivicSuite/civiccore/releases/download/v1.2.1/civiccore-1.2.1-py3-none-any.whl#sha256=<hash>"

Confirmed in townlight/code, townlight/meetings, townlight/access, townlight/notice (each pins a specific historical version — 1.2.1, 1.2.1, 1.2.0, 1.2.0 respectively — with a per-version sha256). One outlier, townlight/boards, has a bare civiccore==0.3.0 pin with no index configured, which won't resolve via pip install as-is — a pre-existing issue in that repo, unrelated to this rename.

Implications for follow-up work in sibling repos (out of scope here, not touched):

1. gh api confirms release assets for v1.2.1 etc. already resolve at https://github.com/townlight/core/releases/download/... (the GitHub org/repo rename already redirects/relocated them), so existing pins likely still work today.
2. The next release cut from this renamed package will produce a wheel named townlight_core-<version>-py3-none-any.whl (normalized from the townlight-core distribution name) with a new sha256 — every sibling repo's dependency line will need updating to the new URL/filename/hash before it can upgrade past v1.2.1.
3. townlight/boards's existing civiccore==0.3.0 pin is already broken independent of this rename (no configured index) and should be flagged separately.

Verification

• pytest tests/ — 265 passed, 37 skipped (all skips are pre-existing "Docker daemon not reachable" skips for testcontainers-based tests; same skip set before and after this rename). CI's ubuntu-latest runners have Docker, so these should run in CI.
• ruff check . — 197 errors after vs. 196 before this rename (pre-existing style lints — I001/RUF022/UP035/BLE001 etc. — unrelated to this change; verified by diffing ruff output against the pre-rename main branch).
• python -m build — produces townlight_core-1.2.1-py3-none-any.whl / .tar.gz as expected.
• Regenerated USER-MANUAL.docx/.pdf via scripts/gen-user-manual.py so all manual formats match USER-MANUAL.md.

Known follow-up (not blocking this PR)

• The workflow_dispatch "cleanroom-rehearsal" job in release.yml defaults release_tag to v1.2.1 (the real latest release) but now expects the new townlight_core-<version>-py3-none-any.whl naming — it won't successfully rehearse v1.2.1 specifically until a new townlight-core-branded release exists. This is an expected transitional state, not a bug.

Test plan

• pytest tests/ green locally
• python -m build produces correctly-named artifacts
• CI green on this PR (reported separately once available)

[scottconverse]

CI status

Both checks (tests, cleanroom) are failing on the same single root cause, unrelated to this rename: pre-existing ruff lint debt on main itself, exposed because pyproject.toml pins ruff>=0.11.0 (no upper bound) and CI now resolves ruff 0.16.2, which enables more default lint rules than were active when this repo's CI last ran green (2026-07-22, PR #69).

Evidence:

• Checked out pre-rename main (commit d31144f) in a worktree and ran the exact CI-pinned ruff==0.16.2 against it: 172 pre-existing findings (import sorting, UP035, TRY004, BLE001, stale noqa comments, etc.) — none related to branding.
• Ran the same ruff version against this branch: 173 findings, of which 172 were the identical pre-existing findings (just shifted to different column numbers because townlight_core is 5 characters longer than civiccore) and exactly 1 genuinely new finding (townlight_core/models/__init__.py — a single import line pushed past the 100-char limit by the longer package name).
• Fixed that one real finding in a follow-up commit. This branch is now at parity with main: 172/172, i.e. zero net-new lint findings from this rename.
• scripts/verify-release.sh treats any ruff finding as a hard failure, and both the tests job and the cleanroom job call it, so both fail identically on the same 172 pre-existing findings. Every other step in verify-release.sh passes on both jobs: full pytest suite green, version lockstep, release-provenance fixtures, required docs present, python -m build, and the fresh-virtualenv install/import smoke test.
• One cleanroom run also hit a transient curl: (56) Connection died while downloading the pinned cosign binary during the Docker build — a network blip unrelated to this PR; re-running it landed back on the same ruff failure, confirming ruff is the actual gating issue.

This pre-existing lint debt is out of scope for a packaging/branding rename PR to silently absorb via a mass ruff --fix across ~170 unrelated findings in files this PR didn't otherwise touch — that would bloat and muddy this diff. Flagging here so a maintainer can decide whether to pin ruff to the version last known-green, or take on the lint cleanup as its own PR.