feat(memory): gate writes on decision-model evidence sufficiency

[AlexStocks]

Stacked on #1740. This branch is based on that PR's head, so the diff below currently also
contains #1740's changes. Please review #1740 first; once it lands, this PR's diff shrinks to the
files listed at the bottom.

Related to #1644. That issue asks whether a decision model can judge semantic relevance and
evidence coverage. This PR implements the consumer for the evidence-sufficiency half, behind a
default-off switch. It closes nothing.

Rationale for this change

#1740 added a decision role to the Runtime but deliberately shipped it with no consumers. This PR
adds the first one: a write-time evidence gate for Memory.

When a Memory write arrives — from automatic extraction or from an explicit remember — the gate
asks one bounded question: does the cited evidence actually cover the claim being stored? Today
only the existence of the cited ids is checked; sufficiency is not checked at all. A model-backed
gate can judge that, at a fraction of the cost of routing the whole write through a general
generation model.

The verdict is advisory, and a refusal is visible

This is the part worth reviewing closely.

• ACCEPT — the write proceeds unchanged.
• FLAG — the write proceeds, annotated. The gate fills the change's reason only when the
  candidate did not already carry one, so it never overwrites an existing explanation.
• HOLD — the write does not happen, and the caller is told why, through structured
  refusal rather than a log line:
  • automatic extraction: flush() returns held_count / hold_codes, and the window cursor
    still advances;
  • explicit remember / revise: MemoryWriteRejectedError is raised, carrying code and
    reason;
  • any plan_remember caller: reads MemoryWritePlan.decision directly.

A HOLD is not routed to the Review Inbox, and that is deliberate. For Memory, an unstored
observation is not a pending review item: regular Memory writes commit directly, and rejected
content is corrected through its existing revision semantics. The inverse of a silent drop is a
visible, reasoned refusal — not a queue. Reuse of needs_evidence and
evidence_limit_exceeded keeps the refusal vocabulary consistent with the existing evidence
resolution errors; insufficient_coverage is added for the case where evidence exists but does not
cover the claim.

Fail-open, and no thresholds

• If the gate is unavailable — not configured, ABSTAIN, or used_fallback=true — the write
  proceeds. A gate that cannot judge must never be the reason a memory is lost.
• The gate is disabled by default and makes no model call until it is switched on.
• Enabling the gate while no decision backend is available does not fail startup. This is
  deliberately the opposite of the decision role itself, which fails fast when it is explicitly
  enabled with an unusable backend: the gate is auxiliary and fail-open by contract, so it logs a
  structured warning naming the event and passes writes through. A misconfigured gate must never
  block Memory writes — but it must never do so silently either.
• A gate passed in explicitly takes precedence over one built from configuration.
• One combined configuration is worth naming: if the decision role itself is enabled with no usable
  backend, startup fails fast by design, and the gate's pass-through warning is emitted first. The
  failure still belongs to the decision role and the outcome is correct; only the order of those two
  log lines is arbitrary.
• No threshold values are shipped. The configuration exposes a direction only
  (memory_write_gate_hold_on), with the threshold left unset. Which direction a backend's
  confidence actually points is a property of that backend and must be established by probing it
  with a known-answer pair (a real preference versus filler) before a value is trusted. The
  contract tests carry that probe, including a case where a reverse-polarity backend makes the
  probe fail.

What changes are included in this PR?

• runtime/memory_write_gate.py — the decision-backed gate adapter, plus DecisionKind values for
  the two consumers.
• artifacts/memory/protocols.py — the gate's value objects and port (MemoryWriteGate,
  MemoryWriteGateRequest, MemoryWriteAssessment, MemoryWriteVerdict,
  MemoryWriteRejectionCode). They live in the Memory family rather than in runtime/ because the
  Runtime package eagerly imports relational → memory.service → protocols; putting them in
  runtime/ would force a reverse import and create a cycle. The dependency direction stays
  one-way: runtime → memory. All public names remain importable from
  powercontext.builtin.runtime.memory_write_gate.
• artifacts/memory/service.py — assessment between candidate selection and commit preparation.
• artifacts/memory/errors.py — MemoryWriteRejectedError(code, reason).
• runtime/relational.py, runtime/models.py — a held write does not store Memory, does not
  interrupt the window, and is reported through held_count / hold_codes.
• runtime/application.py — explicit writes surface the refusal through the existing error
  channel.
• runtime/composition.py — resolves the gate for the public runtime API: an explicit injection
  wins, configuration otherwise builds one, and an enabled gate with no usable backend logs a
  structured warning and passes writes through rather than failing startup.
• runtime/config.py, .env.example — the gate's settings.
• Three test modules.

Are there any user-facing changes?

Yes, but only when the gate is switched on:

• Three new settings; all inert by default, and all three are read by production code — this PR
  deliberately adds no setting that nothing consumes.
• MemoryFlushResult gains held_count and hold_codes (defaulted, so existing readers are
  unaffected), and MemoryWriteRejectedError is a new exception which callers of explicit writes
  may now receive.

With the gate off, nothing is constructed, no model call is made, and every write behaves exactly
as before. When on, a refused write surfaces to the caller; it is never silently discarded.

No new dependency; pyproject.toml and uv.lock are untouched. No persistence schema change.

How was this change tested?

• ruff check . — All checks passed
• ruff format --check . — 890 files already formatted
• ty check --python-version 3.11 <changed src files> — All checks passed
• Global ty check — no diagnostic points at any file in this PR
• The modules this PR adds or changes, plus the HTTP API contract — 78 passed
• pytest tests/builtin/runtime — 478 passed, 7 failed on the development host

The seven failures are all tests that spawn a real child process and then time out. They are
attributed to host load rather than to this change: one of them fails in isolation as well, none of
the affected modules reference the gate, and 478 + 7 = 485 matches the count from an earlier green
run of the same suite on the same code path. CI runs this suite on four Python versions, and every
tests (3.11) through tests (3.14) job is green on this commit, together with quality,
windows-unit-portability and both Acceptance jobs.

The behaviour was exercised through all four paths — accept, flag, hold, and fail-open — including
asserting that a held automatic write advances the window without storing Memory, that a held
explicit write raises with code and reason readable by the caller, and that an unavailable gate
lets the write through.

Two of these assertions were additionally validated by mutation, so that they are load-bearing
rather than incidental:

• Removing the guard that preserves an existing candidate reason makes the flagged-write
  regression fail with 'evidence is thin' != 'an explicit reason'.
• Renaming the structured event on the pass-through warning makes the unavailable-backend test
  fail, reporting the event set it actually observed.

AI usage statement

AI assistance was used to develop this change: the implementation and its tests were produced with
a WorkBuddy agent (Claude-family model) working from a human-reviewed design. The diff, and every
command listed above, were reviewed and run by the author before opening this PR.

[AlexStocks]

@Teingi I have handled all your review comments. please review this pr again.

[AsperforMias]

LGTM. Reviewed the current head, including gate assembly in background workers, per-candidate evidence resolution and budgets, and visible refusal through explicit writes and automatic processing. No blocking issue found. The model-quality experiments in #1644 remain follow-up scope, as stated in the PR.

[AlexStocks]

@Teingi please review it again.

[AlexStocks]

Pushed b629207b to fix the latest CI failures.

Root cause: the R8 hermetic Topic Memory test used a 20s spawned worker timeout, which was too tight for Python 3.13/Ubuntu cold startup before topic generation. The worker could time out before publishing a searchable topic. I raised that bounded test timeout to 60s and also updated the R8 worker-failure capture to recognize the current artifact_processing.failed supervisor event so future failures keep their redacted classification.

Validation:

• WSL SETUPTOOLS_SCM_PRETEND_VERSION=1.1.1.dev0 UV_PROJECT_ENVIRONMENT=.venv-linux-313 uv run --python 3.13 pytest tests/e2e/test_topic_memory_product_chain.py::test_r8_e0_runs_the_complete_hermetic_topic_product_chain tests/e2e/test_topic_memory_product_chain.py::test_worker_failure_capture_records_current_supervisor_event -q (2 passed)
• uv run --no-sync ruff check tests/e2e/topic_memory_product/common.py tests/e2e/topic_memory_product/harness.py tests/e2e/test_topic_memory_product_chain.py
• uv run --no-sync ruff format --check tests/e2e/topic_memory_product/common.py tests/e2e/topic_memory_product/harness.py tests/e2e/test_topic_memory_product_chain.py
• uv run --no-sync ty check --python-version 3.11 tests/e2e/topic_memory_product/common.py tests/e2e/topic_memory_product/harness.py tests/e2e/test_topic_memory_product_chain.py
• GitHub checks are now green, including the previously failing tests (3.13) and Acceptance (sqlite).

[AlexStocks]

Verified at b629207b: I have marked 12 fixed review threads as resolved, including the four confirmed fixes from the latest review. Thank you for addressing those.

Five P2 threads remain open. A fresh replay with isolated databases confirms:

• Candidate-to-citation mapping: (A\nB, C) and (A, B\nC) with the same per-index citations still produce identical complete judge requests. The latter persists B+C citing only sourceC.
• Refusal visibility: The spawned worker holds an over-budget candidate, advances cursor/ack, and reports succeeded without exposing the refusal to its parent. The timer's JSON output also drops refusal codes/counts.
• Injected gate in workers: The parent holds a direct write, but the child ignores the injected gate and persists the contradictory candidate.
• Local Source projections: A registered short text projection is rejected as evidence_limit_exceeded before the gate is called; the same write succeeds with the gate disabled.
• Explicit Artifact family: An input retaining family='skill' is persisted as an experience reference even with the gate disabled.

The candidate-mapping and refusal-visibility fixes still have uncovered paths; the other three findings concern additional cases. Please address these five before merge. Their existing threads contain the reproduction details and required behavior.

This replay used fresh SQLite databases, actual spawned workers and a real scheduler timer with controlled gate/model responses. It did not rerun external-model or OceanBase validation.

done