fix(themes): stop archived theme pages from blocking their entity set

[dripsmvcp]

closes #704

what

themes._existing_theme_entity_sets walked store.list_pages() with no
lifecycle filter, so an archived theme page kept contributing its entity
frozenset and propose_theme treated that cluster as already taken.

Archive is how an operator retires a wrong theme — and this made the
retirement permanent for that entity cluster. The only way to re-synthesize it
was hand-editing storage. Same one-way trap compile's TAKEN TOPICS had
(#700).

Claims were already excluded here through _EXCLUDED_STATUSES, which includes
ARCHIVED. Theme pages were not.

the fix

Skip PageStatus.ARCHIVED when building the existing entity sets. The
type == "theme" filter the issue also suggests was already in place, so the
diff is the one lifecycle check.

Pending proposals deliberately still count: awaiting review is not retirement,
and two proposals for one cluster is exactly the duplicate this guard exists to
prevent.

tests

Four in tests/test_themes.py:

• an archived theme page no longer contributes its entity set (the issue's
  repro)
• a live one still does — the filter is archive-only
• a pending proposal still blocks, so the dedupe guard is not weakened
• end to end: propose a theme, approve it, confirm detect_themes dedupes the
  cluster away, archive the page, and confirm the cluster resurfaces

Full gate green locally: pytest tests/ --ignore=tests/embeddings, mypy src,
ruff check src tests, plus diff-cover --fail-under 100 on the changed lines.

Sibling of #700 (compile) and #701 (provenance graph) — same archive leak,
three different surfaces, one PR each and no file overlap between them.

[plind-junior]

read this alongside #709, #708, #698 and #697 — five PRs, one bug class, and the cluster is worth a word on its own.

the fix here is right and the test set is the best of the five: the end-to-end case (propose → approve → confirm dedupe → archive → confirm the cluster resurfaces) is the one that actually proves the user-visible behaviour rather than just the predicate. holding pending proposals in the guard is also the correct call, and it is good that a test pins it.

one cross-cutting note. context._page_is_live already exists and its docstring is explicit about why: "pages are only ever tested, so the check lives here once — keeping it in three places is what let kb.context keep serving archived pages after #581 fixed kb.search." this cluster now adds five more copies of that predicate — an inline is PageStatus.ARCHIVED here, another in provenance/graph.py, a _live_pages helper in compile.py, a near-verbatim copy of _page_is_live in graph._neighbor_ok, and a list comprehension in cli.render_wiki_cmd. the sixth surface will be a sixth copy.

_live_pages(store) from #708 is the shape that fits three of the five — the ones iterating store.list_pages() and already holding the Page. suggest promoting it next to _page_is_live as page_is_live(page: Page) -> bool, with the store-and-id form delegating to it, and landing this cluster on it so the next surface is a one-line import rather than a sixth reimplementation.

nothing blocking in this diff.

[github-actions]

diff coverage: n/a — this PR changes no python under src/vouch/, so there is nothing for the gate to measure.