fix(perms): propagate sender/role through MCP bridge & delegate (#915)

[mozaa-solana]

Summary

Group-scoped permission checks (CheckCronPermission / CheckFileWriterPermission) deny with senderID="" when tools are invoked through:

1. MCP bridge (external CLI providers like claude-cli, opencode-go) — the bridge middleware never injected SenderID/Role into ctx, so even though the agent loop sets them on RunRequest, the bridge layer dropped attribution. Result: any group cron / file_writer mutation called via the bridge denies as "system context".
2. delegate tool (gateway_managed.go delegateRunFn) — built RunRequest without copying SenderID/Role/Channel/ChatID/PeerKind from DelegateRequest, so the target agent's loop_context.injectContext skipped WithSenderID and downstream group cron/file_writer mutations denied with senderID="".

Changes

• internal/providers/claude_cli.go — new OptSenderID, OptRole.
• internal/providers/claude_cli_mcp.go — BridgeContext carries SenderID+Role; writeMCPConfig emits X-Sender-ID/X-Role headers and signs them in the HMAC payload (extras: localKey | sessionKey | senderID | role). VerifyBridgeContext gains a backward-compat fallback that drops the last 2 extras for sessions written pre-this-change.
• internal/providers/claude_cli_session.go — bridgeContextFromOpts reads new opts.
• internal/gateway/server.go (bridgeContextMiddleware) — read X-Sender-ID+X-Role headers (HMAC-protected), inject WithSenderID/WithRole into ctx.
• internal/agent/loop_pipeline_callbacks.go — pass req.SenderID/req.Role into chatReq.Options.
• cmd/gateway_managed.go (delegateRunFn) — propagate SenderID/Role/Channel/ChatID/PeerKind from DelegateRequest into RunRequest.
• internal/tools/team_tool_dispatch.go + cmd/gateway_consumer_normal.go — slog.Warn when sender is empty in a group-target dispatch so admins can find upstream callers losing attribution.
• internal/store/config_permission_store.go — surface diagnostic-rich error messages (which user/scope/configType denied) instead of generic "permission denied".
• internal/tools/cron.go — forward the diagnostic message to LLM result so the agent can self-correct.

Test plan

• go build ./... clean
• go test ./internal/providers/... ./internal/store/... ./internal/gateway/... ./internal/agent/... passes (incl. TestVerifyBridgeContext HMAC fallbacks)
• Reproduced the cron-in-Telegram-group denial, applied this fix, retested, cron now works for whitelisted users
• Backward compatibility verified: pre-existing MCP config sessions (without senderID/role headers) still match the older HMAC fallback in VerifyBridgeContext.

Related

Follow-up to #915. Diagnostic logs added in this PR are the ones I used to localize the root cause; happy to drop them if reviewers prefer.