[finding] captureEngine's pass-through lands in a silenced logger, so its documented "unrecognised frames still reach the log" does not hold under a silent kernel #11569

Filed unassigned by the seat implementing #11081. Observation class — no pm:queue.
Backlink: PR for #11081 (branch claude/issue-11081-expected-noise-capture-pin).

What was measured

packages/runtime/src/expected-read-refusal-noise.ts states its central invariant twice
in its own header:

• it withholds ONLY the expected fault …; anything it does not recognise still reaches
  the log;

and, for the engine gate specifically:

⛔ … A DATABASE_ERROR on one of the same tables arising from any OTHER cause is not
recognised by the driver sink, so its frame is not withheld here either — it reaches
the log with both halves intact.

That holds on the driver channel and does not hold on the engine channel.

captureDriver installs a sink whose non-matching branch calls console.warn /
console.error directly, so an unrecognised driver fault bypasses the kernel logger
and is genuinely loud.

captureEngine installs a Proxy whose non-matching branch calls target.error(msg, err, meta) — where target is the engine's own logger, i.e. the kernel-derived one. Every
fixture that carries this capture also constructs its kernel with
logger: { level: 'silent' }, so ObjectLogger.isEnabled('error') is false and write()
returns early. The frame is dropped.

Measured on origin/main at 4c9780c7, running each fixture as-is (no mutation), counting
ERROR Find operation failed frames reaching the log:

Zero is the expected count for the recognised frames — they are withheld on purpose. The
finding is that an unrecognised engine frame scores zero too, for the same reason, and
nothing distinguishes the two.

Why it is worth a card rather than a shrug

The asymmetry is invisible at the call site. A fixture author reads the header, sees
"anything it does not recognise still reaches the log", and reasonably concludes the engine
channel is pinned in both directions. It is pinned in one: the afterAll
silentChannels() assertion still fires correctly if a recognised frame stops being
emitted (that half is real and was demonstrated for #11081). What does not work is the
other half — a new, different engine ERROR on the same object appears nowhere.

captureExpectedReadRefusals is imported by 16 packages/runtime fixtures today, plus the
two added by #11081, so this is a shared surface rather than one file's quirk.

Not claimed

• ⛔ No test is shown to be wrong. Every affected fixture passes, and the counting /
  assertion half of the capture behaves exactly as documented.
• ⛔ Not a proposal to make captureEngine call console.error directly. That would
  make all 18 consuming fixtures loud on a channel they currently expect to be quiet, and
  the right shape (a caller-supplied sink? a level floor? leaving the engine channel to the
  driver channel that already carries the same fault?) is a decision, not a cleanup.
• ⛔ Not blocking [finding] Five fixtures now blanket-silence their kernel, hiding unexpected ERROR output — the expected-noise capture pin is the strictly better shape #11081. The PR there pins the driver channel, where the backend's own
  diagnostic actually lives, and records this gap explicitly rather than overclaiming.