feat(engine): loop-brake — trip the supervisor on repeated non-advancing results

[mgoldsborough]

Follow-up to #361. That PR fixed the cache bug that made a bundle's tools invisible; this adds the behavioral brake for the other half of the same incident — an agent that re-searches for a capability that genuinely isn't there instead of stopping.

Problem

The loop supervisor fingerprints (toolName, isError, content[, input]) and trips after N identical fingerprints. A discovery loop slips through every axis: the model calls nb__search with a fresh query each turn and gets a distinct No tools matched "<query>" back, so content and input vary and the fingerprint never repeats — the run burns iterations to the cap. Input-aware success fingerprinting (#324) makes this structural: a varied input reads as progress.

Fix

A third "stuck" axis: a tool may mark a result non-advancing. The supervisor collapses consecutive non-advancing results from one tool to a single canonical fingerprint, so N in a row trip regardless of how input/content varied; the tool is then disabled for the run and the model is nudged to surface the gap.

Why _meta (and not structuredContent or a top-level field)

The signal is metadata about a result, not the tool's data — so it belongs in MCP's _meta, the blessed out-of-band channel, under a reverse-DNS key (ai.nimblebrain/non-advancing, matching the spec's own io.modelcontextprotocol/… convention). A top-level ToolResult field is dropped at the MCP boundary every tool result crosses (in-process system tools included); structuredContent is the tool's data payload and overloading it is a smell. _meta is the correct container and round-trips by construction.

To make it reachable end-to-end:

• ToolResult gains a _meta slot mirroring CallToolResult._meta.
• The in-process tool boundary forwards result _meta onto the wire; McpSource reads result-level _meta back on both the inline and task paths. _meta is a looseObject per the MCP schema, so arbitrary reverse-DNS keys survive — verified by a round-trip test through a real in-process MCP transport (not just schema-reading).
• nb__search's no-match branch sets the key. Any tool, in-process or bundle, opts in the same way.

The supervisor reads the flag by key, not by folding _meta into the hash — so the input-aware success path is untouched.

Composition

• With fix(supervisor): input-aware fingerprint for success results #324 (input-aware success fingerprint): that fixed false trips on progress; this fixes missed trips on no-progress. The two are the false-positive and false-negative halves of the same "is this call advancing?" question.
• With fix(tools): rank natural-language tool search #260 (ranked search): fewer reasonable queries come back empty in the first place, so this brake fires only when a capability is genuinely absent.

Tests

• Round-trip (non-advancing-meta.test.ts): a tool's _meta set in its handler survives the in-process MCP boundary and lands on the engine-side ToolResult._meta. Empirical proof the channel works.
• Supervisor: 3 non-advancing results trip even with input+content varying every call; an advancing result resets the streak; varied-input real work (patch_source-style) still never trips. Verified red without the _meta fingerprint branch.
• nb__search: no-match sets the _meta key; a match does not.

Full verify green locally: static checks, 3316 unit + 666 integration tests, 0 failures.