Any current operator can forge a successful Teams capability-use result

Reproduction steps:

1. Create a Team with a requester, a capability holder, and a second member who has the operator role.
2. Create a pending uses_out record for a capability request owned by the holder.
3. From the second operator member, create a valid signed capability_use_result envelope addressed to the requester.
4. Encrypt a result containing the existing use_id, ok=true, and arbitrary result/receipt_ref values.
5. Deliver the envelope through the normal team_mesh.receive() path.
6. Read the requester's use status.

Expected:
Only the holder identified by the grant may resolve the pending capability request. A result from another operator must be rejected and must not change the pending status.

Actual:
The envelope passes mesh verification because capability_use_result only requires the sender to be a current operator. The result handler updates the request to status=done and stores the attacker-supplied result and receipt_ref.

Station version (railcall version): station-v0.68
Module slug + version: Not module-specific; Teams capability path

Root cause:
workbench/primitives/team_mesh.py authorizes capability_use_result by sender role only. workbench/primitives/team_share.py::_handle_incoming_result() matches only use_id and never verifies env.from_pubkey against the grant's holder_pubkey.

Impact:
A Team operator can create a false successful completion record for another member's capability request, including a false result/receipt reference. No external provider call is required to reproduce the integrity failure.

Control:
The same mesh path rejects senders who are not current Team members; the missing check is specifically the holder identity binding.