feat: return the acting wallet on sponsored executions

### Before filing

- [x] I searched open and closed issues for this proposal.
- [x] I checked the docs and the current behaviour on `staging`.
- [x] This is one change, not several. (Several means several issues.)

### Reason: what you cannot do today

With gas sponsorship the explorer shows the relayer as `from` (docs/wallet-management/onchain-appearance.md). Seen on Base Sepolia on 12 Sep 2026: sender 0x6331eb4571DE9284f7E9eAD98ac7b0661a091E99, target the relay contract, and the organization wallet appears only in the event arguments. `GET /api/execute/{id}/status` carries `sponsored: true` but no sender.

### Reason: what the workaround costs

A framework that reads receipts to track positions (Almanak's receipt parsers key on the acting wallet) has to derive the actor from event arguments, per event signature. I wrote that decoder for Transfer, Approval, Deposit and Withdraw. A reviewer opening the explorer cannot tell which org wallet moved the funds without it.

### Scope: what this touches, and what it does not

In: `GET /api/execute/{id}/status` and the 202 envelope of the three write routes gain a `sender` field. Out: workflow executions, Solana. One change.

### Plan: what you propose

Add `sender` (the organization wallet that is `msg.sender` for the call, whether or not gas was sponsored) next to `sponsored`; document it in direct-execution.md under "Sponsored Executions". Existing callers are unaffected; the field is additive.

### Plan: alternatives you considered

- Do nothing and document the event-argument method (what the Almanak integration ships today).
- Put the org wallet into the explorer view via a label: not something the API can do.

### Scope: compatibility

- [ ] Changes an existing response shape, status code, CLI flag, or default.
- [ ] Adds, removes, or upgrades a dependency.
- [ ] Changes database schema or requires a migration.
- [ ] Touches authentication, permissions, validation, or spend limits.
- [ ] Changes pricing, plan limits, or anything a user is charged.

Start by tracing GET /api/execute/{id}/status and the 202 response envelopes for the three write routes, focusing on how sponsored execution data is assembled. Then read docs/wallet-management/onchain-appearance.md and direct-execution.md under "Sponsored Executions"; done means the additive sender field identifies the organization wallet and the behavior is documented.

Written by the indexing model from the issue text.