[COAZ-MCP] Bind a permit to the MCP operation actually forwarded

[sapsan14]

Problem

The current COAZ-MCP processing algorithm populates the mapping inputs from an
MCP request, obtains a permit/deny decision, and then allows the message to
proceed. It does not explicitly state that the operation forwarded or executed
must still be the operation that produced the authorization request.

For example, a gateway pipeline could evaluate:

{
  "method": "tools/call",
  "params": {
    "name": "payments.send",
    "arguments": { "amount": 500 }
  }
}

and obtain a permit, after which a later middleware stage changes amount,
name, or even method before forwarding. The PDP response is valid, but the
PEP has applied it to a different operation.

This is separate from obligations/constraints in #521 and from post-action
receipts. It is the pre-execution authorization-to-use boundary.

Suggested clarification

In the Processing Algorithm and/or Mapping Integrity security consideration:

• The PEP MUST evaluate the final normalized operation that it will forward or
  execute.
• A permit applies only while the inputs that selected the mapping or
  contributed to the constructed AuthZEN request remain semantically unchanged.
• If any such input changes after evaluation, the PEP MUST re-evaluate the final
  operation or refuse it; it MUST NOT reuse the earlier permit.
• Rewrites or other known transformations that can affect mapping selection or
  mapped values MUST occur before mapping resolution and evaluation.
• If the MCP server re-authorizes a gateway-forwarded request, the same rule
  applies between the server's evaluation and local execution.

“Semantically unchanged” should be defined over mapping-selection inputs and the
binding's input-variable values, not over raw JSON bytes, so harmless
serialization or transport normalization remains possible. Fields deliberately
excluded by a medium-grained mapping are not implicitly made fine-grained by
this rule.

Candidate negative vectors

1. unchanged tools/call after permit → forward;
2. mapped tool name changed after permit → re-evaluate or refuse;
3. mapped arguments changed after permit → re-evaluate or refuse;
4. method changed after permit → re-evaluate or refuse;
5. mapped trusted context changed after permit → re-evaluate or refuse.

Would the WG prefer this as an additional normative processing step, or as a
Mapping Integrity requirement plus conformance vectors?