fix(mcp): report unretained partial Evidence when retention fails - #10504

Summary

Fixes #8425.

When toPartialErrorToolResult records a completed partial observation and the ledger refuses it, deliver that observation as partial_observation.kind: "unretained-evidence" together with partial_observation_retention_error, instead of inline-evidence with retention: "unknown". Callers can distinguish completed-but-unretained Evidence from retained references, and the original retention diagnosis stays visible. Overflow omission reports retention: "unretained".

Problem and expected behavior

After a tool completed a partial observation, a retention refusal still labeled the returned Evidence as inline-evidence with retention: "unknown" and dropped the retention error projection. Expected: preserve the completed observation as unretained Evidence, surface the retention failure, and never advertise a ledger reference for an uncommitted record.

Change and scope

Update ToolResultDelivery.toPartialErrorToolResult only: on recordEvidence failure, attach unretained-evidence plus projectAnalysisErrorWithoutPartialObservation(recorded.error). Overflow compaction already omits unretained candidates; tests now expect retention: "unretained". No new retention admission, CLI paths, or provider changes.

Follow the contribution scope.
Unresolved scope, authority, side effects, or required verification block
integration. Link the required maintainer scope decision for new providers or
capabilities involving target execution, injection, mutation, or protection
recovery; ordinary fixes within existing boundaries may state "not applicable".
Draft PRs may leave the scope decision pending and the readiness and merge checklists
unchecked. Maintainers can help resolve open questions.

Contract and boundary impact

• Semantic owner and earliest changed stage: MCP ToolResultDelivery.toPartialErrorToolResult; consumers of partial-observation error details.
• Contribution scope fit and linked maintainer decision: ordinary fix within existing Evidence delivery; not applicable.
• CLI and MCP/tool-catalog contract: error details.partial_observation kind/retention vocabulary for this path; no tool schema change.
• Provider, bridge, target-format, or platform compatibility: none.
• Evidence, artifact, provenance, or reconstruction contract: refused partials are labeled unretained and carry the retention error projection.
• Target selection, authority, upstream behavior, and cleanup details (if applicable): none.
• Generated metadata (docs/public/product-catalog.json), package, or installation impact (CI generates and validates ignored catalogs and skills/; edit authored instructions in .agents/skills/reverse-engineer-anything/ and never commit build outputs): none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

• Read existing files or captured data.
• Launch or attach to a process.
• Inject instrumentation or run scripts/code.
• Change process memory, registers, files, or configuration.
• Contact network services.
• Recover protected code or work around protections.
• Documentation or usability only; no target interaction.
• Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

• Tests added or updated: tests/boundary/mcp/toolResult.test.ts — retention refusal returns unretained-evidence plus retention error code; overflow omission uses retention: "unretained".
• Base reproduction or other evidence: source-derived against current main; on retention failure the prior path emitted inline-evidence / retention: "unknown" without partial_observation_retention_error.
• User-visible CLI/MCP output (if applicable): MCP error details only; no CLI change.
• Remaining proof gaps: does not re-cover the broader shared-admission / authentication-headroom prototypes discussed on [Bug] Evidence retention refusal discards a completed direct observation #8425; scoped to the partial-error delivery path that still used unknown retention.

For boundary fixes, identify the applicable boundary regressions
and lifecycle regressions
covered by the evidence above, and explain relevant gaps.

Boundary: MCP error delivery for refused partial Evidence retention. Lifecycle: not applicable (no session open/close change).

For evidence-bearing changes:

• Observed, derived, and inferred claims remain distinguishable.
• Artifact identity, source provenance, and failed attempts remain preserved.
• Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

• npm run test:focused -- tests/boundary/mcp/toolResult.test.ts tests/boundary/mcp/reverseEngineeringPartialMcp.test.ts tests/boundary/mcp/fridaLifecycleMcp.test.ts tests/boundary/mcp/targetContentFramingMcp.test.ts — 93 passed
• npm run check:fast — typecheck and lint passed

Compatibility, safety, and release

• Breaking changes or migration steps: callers that matched only kind: "inline-evidence" with retention: "unknown" on this retention-refusal path must accept unretained-evidence and partial_observation_retention_error. Successful retention and other error paths are unchanged.
• Real Hopper/Ghidra, browser, or OS coverage: not required; delivery-path unit/boundary coverage only.
• Package or release metadata impact: none.
• Security, privacy, process, or containment review: none; no target interaction.

Author readiness

Human owner: @BeqaKs

• I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
• I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
• I declare this PR ready for initial maintainer review.

Before merge

• This PR addresses a concrete problem or an agreed enhancement.
• Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
• The PR has one focused outcome and the title follows type(scope): outcome.
• Related issue is linked, or the reason for not linking one is stated above.
• Tests cover changed observable behavior and meaningful failure paths.
• Owning docs, contracts, and generated metadata are updated where needed.
• User-visible CLI/MCP changes include representative output.
• I checked the final diff for secrets, unrelated cleanup, and unsupported claims.