bug: on /mcp the guardrail scan text and the mask surface are different texts — block, would_mask and mask disagree

Summary

On /mcp the guardrail scan (which decides block, and which monitor mode
previews as would_mask) and the guardrail rewrite (which actually masks)
run over different texts, in three different shapes. So a rule can block
without ever masking, mask without ever being able to block, and preview as
would-mask while enforcement does nothing — with no error and no signal in
telemetry.

The three texts

Monitor mode inherits the scan text: MonitorGuardrail::probe_redaction
(crates/aisix-guardrails/src/build.rs) runs the redactor over "the hook's
scan text", not over the surface enforcement rewrites.

Consequences

1. A rule anchored to a whole leaf (^…$) can mask but can never block.
   Enforcement offers it the bare leaf, so ^\d{4}$ masks. The scan offers it
   a joined/serialized blob, where ^ is the start of that blob, so the same
   pattern as action: block silently never fires. Block is the stricter
   action — the gap is fail-open.
2. A rule that only matches across the serialized form blocks but masks
   nothing. Anything spanning a key and its value, the "," between two
   members, or the \n the output scan joins with, matches the scan and finds
   nothing to rewrite per-leaf.
3. Monitor mode is unreliable in both directions. Case 2 previews
   would_mask hits and then masks nothing once enforced — the
   accepted-and-echoed-but-never-enforced shape. Case 1 previews nothing and
   then masks once enforced. Either way the documented staging workflow
   (monitor → observe → enforce) does not predict enforcement.
4. Input and output disagree with each other: the input scan sees object
   keys, the output scan drops them.

Suggested direction

Derive the scan text from the same walk enforcement uses, so the two cannot
drift: run the walker with a recording probe that rewrites nothing (the
SegmentCollector in crates/aisix-proxy/src/redact.rs is the existing
template) and scan the collected slots. Then block, would_mask and mask
all see the same slots, and the only remaining choice is whether a rule is
allowed to match across slot boundaries — which becomes an explicit decision
instead of an accident of three call sites.

If that is too large, the minimum is to document the three shapes so an
operator can predict which of their rules works with which action.

Test

• A ^…$ rule with action: block on both hooks must block (case 1).
• A rule seeded with enforcement_mode: monitor must report would_mask
  counts equal to the counts the same rule produces when enforced (case 3).
• Both directions, since the input and output scans differ.

Context

Found by the independent pre-merge audit of api7/aisix#1025. That PR is closed
— its own feature is no longer needed — but this divergence is independent of
it and is present on main today. Supersedes #1026, which described one
symptom of the same root cause from the (now withdrawn) key-context angle.

Start in crates/aisix-proxy/src/mcp.rs and follow collect_string_leaves, rewrite_tool_arguments, and apply_output_guardrails; compare their scan and rewrite paths with SegmentCollector in crates/aisix-proxy/src/redact.rs. Read MonitorGuardrail::probe_redaction in crates/aisix-guardrails/src/build.rs. Done means anchored block rules work on both hooks and monitor would_mask counts match enforced masking in both directions.