Malformed Teams capability requests produce no refusal or result receipt

Reproduction steps:

1. Create a valid Team capability_use_request envelope from a current operator.
2. Encrypt a payload with spend_cents="not-a-number".
3. Deliver it through team_mesh.receive().
4. Inspect the Team inbox and the sender's pending use record.

Expected:
The holder must return an encrypted, signed refusal/result so the requester receives a deterministic fail-closed outcome. The capability protocol states that requests are always answered.

Actual:
The envelope passes mesh verification, then int(payload["spend_cents"]) raises ValueError. mesh.receive() records handler_error and returns without sending capability_use_result. The requester receives no refusal/result.

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

Root cause:
workbench/primitives/team_share.py::handle_use_request() converts spend_cents before entering the answer() path. The exception is caught only by team_mesh.receive(), which logs handler_error but cannot generate a protocol response.

Impact:
Malformed but authenticated requests can leave the requester waiting with no signed denial/result and no deterministic completion state. No external provider call occurs.

Control:
A valid numeric request (for example spend_cents=0) reaches the normal denial/result path and sends capability_use_result.