fix: propagate plugin payload mutations instead of inferring them from text

[araujof]

Closes #151.

A plugin that mutated anything other than a message's text had its mutation dropped: the APL route handler decided "was this modified?" by comparing get_text_content(), which reads Text parts and ignores the other eleven ContentPart variants. Redactors are the plugins that rewrite tool results, so the failure was fail-open this path, and the plugin reported a successful redaction and the host forwarded the original secret.

What the fix turned out to need

The issue suggested the invoker already knows, since result.modified_payload is Some when a plugin returns a mutation. It isn't a signal: PipelineResult::allowed_with sets modified_payload: Some(payload) on every allowed pipeline. Acceptance is only observable inside Executor::run_serial_phase, so that is where it is now recorded, surfaced as PipelineResult.payload_modified.

That also exposed another bug: because the old code keyed off is_some(), every plugin(...) stage in a field pipeline reported a new field value whether or not the plugin mutated, so a non-mutating stage overwrote its field with the message's concatenated text.

Fixes

Each replaces an inferred change with a signal from the code that performed it.

1. Direct mutations reach the host regardless of which content part they touched.
2. Pipeline write-back applies only the paths the pipeline changed, so a pipeline redacting one argument and a plugin scrubbing another both survive. Covers args: and result:.
3. Pipeline modification is read from RouteDecision.args_modified / result_modified, which the handler previously ignored in favour of projecting and diffing.
4. Field-stage dispatch reports a value for the field it was pointed at; a plugin that changed something else reports no field change, and its mutation travels with the payload.

Tests

New tests across three layers. Each mechanism was verified by reverting it and confirming the tests fail:

reverted	failing tests
handler branch conditions	6 e2e
per-path merge only	4 e2e
field readback	2 invoker
executor signal	2 e2e + 1 core
field-name convention	1 apl-core

Coverage includes the content-part variants a plugin realistically rewrites (text, thinking, tool call arguments, tool result), both phases, several plugins accumulating, a denied route forwarding nothing, an audit-mode plugin whose mutation the executor rejects not being reported, omit, and nested paths. The other eight ContentPart variants are not exercised.

make lint clean; full workspace suite green (73 binaries). Each commit compiles on its own.

Behaviour notes for reviewers

• PipelineResult gains a field. Construction goes through allowed_with / denied, so callers using those are unaffected.
• A pipeline writing a field to the value it already held now reports a modified payload where it previously reported none. Fail-safe direction, pinned by a test.
• PluginInvocation::Field.name is now root-relative from do:-block field ops (city, not args.city).
• The workaround in the issue (appending a throwaway text part so the old check fired) can be deleted.

One known limitation is documented in code but not fixed: a field pipeline's interim edits are not visible to a plugin(...) stage later in the same chain. Fixing it changes what every downstream plugin sees, so it wants its own issue.

Plan: docs/plans/2026-08-06-001-fix-modify-payload-propagation-plan.md, including a note on where the plan's premise was wrong.

Additional issues found during self-review:

• A plugin(...) stage undid an earlier mask / redact / hash stage in the same chain. The field readback was compared against the pipeline's interim value, but interim edits never reach the payload — so the payload's untouched original looked like the plugin's new value and was written back. Pre-change this path wrote the message's concatenated text, so the fix had turned field destroyed into plaintext restored. Now compared against the field as the payload held it before dispatch, with a mask | plugin(...) regression test that fails without it. Three reviewers converged on this independently.

Also addressed:

• Merge tie-breaks are documented and logged: args: / result: pipeline edits take precedence over a plugin's edit to the same path (config-author-wins), and a key the plugin removed is reinstated if the pipeline rewrote it. Both warn with the field name instead of resolving silently.
• Removed an unreachable fallback in the result write-back whose wholesale write would have silently reintroduced the clobbering bug this PR fixes.
• payload_modified now crosses the FFI to the Python and Go bindings; the Go Invoke doc example no longer presents ModifiedPayload != nil as a mutation test (it is true on every allowed pipeline). Additive on the wire, ABI version unchanged.
• PipelineResult sealed #[non_exhaustive], mirroring RouteDecision.
• Pre-projections phase-gated; Post-phase field readback now covered; CHANGELOG section order fixed and the Field.name semantic change marked BREAKING.

Deferred: #158 (parallel plugin branches lose each other's payload mutations, and validate_parallel_plugin_modes is never wired into registration, mostly pre-existing, and the reject-at-load vs hold-the-lock choice wants a deliberate call).

[terylt]

Nice work. I read the design doc and traced the correctness-sensitive paths
(executor signal, invoker flag + field_before baseline, the three-way merge,
and the field-name convention). Built locally: 884 tests pass, clippy clean
on apl-core / apl-cpex / cpex-core. The security fix is exact — signals
replacing text-diff inference — and the deferred items (#158, mid-pipeline
payload visibility) are scoped honestly.

One minor suggestion (non-blocking)

In apply_changed_paths (crates/apl-cpex/src/message_projection.rs:203-207),
the key-removal loop resolves silently, while the sibling conflict cases all
warn (warn_on_conflict, plus the both-added branch):

for key in pre_map.keys() {
    if !post_map.contains_key(key) {
        base_map.remove(key);   // drops a plugin's edit to this key with no log
    }
}

So a pipeline omit that removes a key a plugin had just redacted is the one
tie-break in this function that doesn't announce itself — which reads slightly
against the function's own stated bar that "a silent tie-break in this path is
exactly the class of bug this function exists to prevent." The outcome is
correct and safe (the key is gone either way, no plaintext leak); this is purely
observability. A warn! here when the removed key differs from what the plugin
left, mirroring the reinstate case, would close the symmetry.

One note for operators (not a change request)

Worth calling out in the changelog/behavior notes: the fail-safe direction means
payload_modified now trips Some on more requests than before (a plugin
returning an untouched clone, or a pipeline writing a field to its existing
value). Inside the engine on the pure-Rust path this is cheap — Value clones
and a Message clone, no serialization. But a host that keys its wire
re-encode off "did the payload change?" (and the FFI msgpack step) will now
run on somewhat more routes. Correct trade — a false positive costs one re-encode,
the false negative was the bug — just want it visible so nobody reads a small
throughput shift on mutating routes as a regression.

[terylt]

LGTM