operationalize_design.py --apply: pre-filled Issue cells assume OPEN, never check real state nf-k8qf ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/941 by tools/beads/import_github.py's reconcile pass.

Found while running --apply for design 008 T4 (#939)'s 005b backfill.

apply()'s per-row loop (design_docs/tools/operationalize_design.py:261-271) has two paths to an issue number:

• Found via list_task_issues (title matches <doc_id> T<n>: …): issue_number, issue_state = existing.number, existing.state — the real state, from gh.
• Found via a pre-filled Issue cell the doc's table already carries (elif row.issue is not None): issue_number, issue_state = row.issue, "OPEN" — hardcoded, never actually checked.

For a task whose existing issue predates the <doc_id> T<n>: … naming convention (so list_task_issues can't find it, but the doc's Issue column is hand-filled with the known number to avoid minting a duplicate — exactly what 005b T6/#756 needed), this means the Project item's initial Status is always set to Backlog even when the real issue is closed. Not a correctness bug for --apply's own idempotency (a re-run still finds the item via project_status and skips), just a wrong initial status on first run that has to be hand-corrected afterward.

Fix: the elif branch should look up the issue's real state (a gh issue view <n> --json state or equivalent single-issue read) instead of assuming OPEN, or apply()'s status-setting logic should not special-case "found via list_task_issues" vs "found via pre-filled cell" at all.

Unclaimed — filing per CLAUDE.md's "strategic uplifts: file them, don't claim them."