feat(harness): add QuestionResolver Protocol + --interactive CLI flag (stacked on #365)

[mlieberman85]

STACKED ON #365. Do not merge before #365. Until #365 lands on main, this PR's diff includes all of #365's changes plus feature 027. After #365 merges, this branch will be rebased onto main and the diff will collapse to feature 027 only.

Summary

Adds --interactive to darnit harness and a new QuestionResolver Protocol that sits downstream of feature 026's AnswerSource chain. Where AnswerSource is passive preloaded-value lookup, QuestionResolver is active resolution -- ask a human, call an API, open an issue. Interactive terminal today; A2A / GitHub-issue-comment / Slack / webhook adapters plug in via entry points tomorrow, without any change to darnit-core.

Detailed rationale in the commit body.

What ships as user-visible

• New CLI flag: darnit harness --interactive prompts the operator at /dev/tty for any feedback question not covered by --answers or .project/project.yaml. Fail-fast (<2s, exit 2) when stdin is not a TTY OR /dev/tty is not openable.
• New Protocol: darnit.harness.question_resolvers.QuestionResolver -- third-party resolver authors can register via Python entry points under darnit.question_resolvers (matches the existing darnit.frameworks discovery pattern).
• Extended report: per-question resolution_trail captures which resolvers were offered a question and how each responded (answered / skipped / errored). New answered_feedback list surfaces per-answer origin + authority.

Constitution notes

• IV (Never Guess User Values): reinforced. Answer.authority is a Literal[\"asserted\"] with a fixed default -- resolver authors physically cannot construct an Answer with a different authority (Pydantic ValidationError at construction). Every answer flowing through this feature carries authority: \"asserted\".
• Feature 026's "no re-audit after collect" MVP policy preserved. A resolver-supplied answer is captured but does NOT silently promote a FAIL to PASS.

What's not in scope

• No re-audit on interactive input (deferred; feature 026's MVP policy applies unchanged).
• Alternative prompt output channels beyond /dev/tty (FR-004a designs the seam; specific event/log sinks are future features).
• Windows terminal support (FR-004a's pluggable channel accommodates it later without a Protocol change).

Test plan

• uv run pytest tests/ -q -- expect 2603 passed (up from 2559 pre-PR: +44 new tests).
• uv run ruff check . -- clean.
• uv run python scripts/validate_sync.py --verbose -- PASSED.
• Manual smoke: uv run darnit harness /path/to/repo --interactive --level 3 on a repo with at least three pending questions. Verify:
  • Ordinary [N/M] progress lines on stderr during audit.
  • Exactly ONE harness: starting interactive collection (N pending questions) line before the first prompt.
  • Prompts appear on the terminal (via /dev/tty), NOT interleaved with stderr.
  • Each prompt has [N of M] position, control_id, question text, optional Help line, and > chevron.
  • Ctrl+C preserves already-collected answers; report is still assembled.
  • Exactly ONE harness: finished interactive collection: X answered, Y skipped, Z aborted line after the last prompt.
• Manual smoke: echo | uv run darnit harness /path/to/repo --interactive -- expect exit 2 in <2s with stderr summary containing interactive channel unavailable (stdin is not a TTY).
• Manual smoke: install the fixture package (uv pip install -e tests/darnit/harness/fixtures/mock_resolver_pkg), run the harness with --interactive on a repo with pending questions -- verify the resolvers-configured log line lists both interactive_terminal and mock_answer / mock_error.

Load-bearing safety properties (test-enforced)

• SC-002 extensibility: tests/darnit/harness/test_extensibility_sc002.py imports a resolver from a fixture package OUTSIDE packages/darnit/src/darnit/harness/, injects it, asserts it's invoked. Fails if the Protocol seam breaks.
• SC-003 asserted authority: 4 tests across test_question_resolvers.py, test_driver.py, test_resolution_trail.py, test_report.py. Includes a Pydantic-level test that constructing Answer(authority=\"dispositive\") raises ValidationError.
• SC-005 fail-fast: two CLI variants (non-TTY stdin, /dev/tty unavailable) both exit 2 in <2s.
• FR-013 no-values-in-logs: driver test uses a distinctive-string mock resolver; asserts the value never appears in any darnit.harness log record.
• RT-10 redaction: _LeakingErrorResolver raises with an embedded sk-ant-* string; the trail's error_summary contains [REDACTED_ANTHROPIC_KEY], not the literal.

Follow-ups (not in this PR)

• Alternative prompt output channels (FR-004a seam only, no implementation).
• Re-audit on interactive input.
• Windows / non-POSIX terminal path.
• Persistence + Constitution IV confirmation timestamp / by-whom (would live in a future "persist interactive answers" feature).

Rebase plan

• When feat: RFC-0001 Stage 1 authority + darnit harness fleet driver #365 merges: git fetch upstream && git rebase upstream/main on this branch, then git push --force-with-lease. The diff will collapse to feature 027 only.

[pxp928]

Approving on the condition that the findings below are addressed before merge. The QuestionResolver Protocol is a good abstraction and the resolution-trail design is sound. But --interactive never actually prompts anyone in production, and the timeout model doesn't hold up. Please don't merge until at least the first three are resolved.

Reviewed the incremental diff pr-365..pr-367 (single commit c10e83b). The asyncio timeout claims were verified with standalone repros. The 8 harness test failures on this branch are pre-existing on #365 (missing framework plugin in my env), not regressions from this PR.

---

Stack note

This branch is stacked on #365, but #370 is also branched off #365 rather than off this PR. So #367 and #370 are siblings and one of them needs a rebase before the stack is linear.

---

Blockers

1. --interactive is inert in production

driver.py:460

Nothing in run_checks, run_sieve_audit, or CheckResult ever populates feedback_questions, so the resolver chain is never offered a question. The whole feature is unreachable on the real path.

What makes this worth blocking rather than noting: #365 carried a comment documenting this exact MVP gap, and this PR deletes that comment while adding user-facing --help text promising interactive prompts. A flag that advertises prompting and never prompts is worse than no flag. Either wire feedback_questions in this PR or keep the gap documented and mark the flag experimental.

2. Operator think-time is charged to the run budget

driver.py:781

Interactive collection runs inside wait_for(_run_body(), total_run_timeout_s). A human thinking about an answer burns the machine budget, and at the next suspension point the expired deadline cancels the run → exit 3, with the report and every answer already collected discarded. Reproduced.

The interactive collect phase needs to sit outside the total-run deadline, or the deadline needs to be suspended across resolver calls.

3. --per-resolver-timeout cannot bound the resolver that ships

driver.py:578

The interactive resolver does a blocking readline() inside an async def. It never yields to the loop, so wait_for never gets a chance to fire and the entire event loop is blocked — the harness hangs indefinitely rather than timing out. Needs run_in_executor / to_thread with the timeout applied around that, or a non-blocking stdin read.

---

Conservative-by-default violation

resolver_discovery.py:113 — non-interactive runs silently invoke every installed third-party resolver, with no opt-in flag, and their answers are recorded as authority: "asserted".

That means an installed plugin can manufacture human assertions in unattended CI. CLAUDE.md is explicit that "human confirmation is the only thing that makes a value usable" and that writing a candidate to disk does not confirm it. Third-party resolvers should require explicit opt-in, and their output should not be able to claim asserted — that authority level should be reserved for a real human in the loop.

---

Should fix

• interactive_resolver.py:52 — _ensure_streams requires both injected streams, but contract IR-23 says /dev/tty must not be opened when either is provided. Single-stream injection silently talks to the real terminal, or raises on CI.
• report.py:39 — PendingFeedbackEntry never gains the answered / answer / answer_authority fields required by this PR's own RT-2a, RT-7, RT-9a and tasks.md T019. Consumers filtering on answer_authority == "asserted" find nothing.
• cli.py:850 — the new answered field changes the exit-summary field order locked by the 026 CLI-13 contract, and that contract file isn't updated. Breaks WARN, (\d+) pending-style CI parsers.
• driver.py:594 — except TimeoutError sits before except Exception, so a resolver raising a built-in TimeoutError is mislabelled as a harness timeout. The trail reads resolver timed out after Nones and the real error is dropped.
• driver.py:588 — unguarded resolver.name inside the exception handlers. Direct injection bypasses the Protocol isinstance check, so a handled resolver error can become an unhandled AttributeError → exit 3, which also skips the close() loop that releases /dev/tty.
• driver.py:679 — post-abort questions increment no counter, so the bookend log undercounts: 10 questions aborted at #4 reports "3 answered, 0 skipped, 1 aborted".