fix(channel/telegram): authorize the account that taps an approval button

[JordanTheJet]

Summary

• Base branch: master
• What changed and why: The Telegram inline-keyboard callback handler resolved an approval verdict from the callback payload alone — it read id and data but never from. Every message path in this channel authorizes the sender against the channel allowlist first; the callback path did not. An inline keyboard is visible to every member of the chat it was posted in, so the tap that answers an approval prompt now runs the same is_any_user_allowed check.
• The verdict path moves out of listen() into resolve_approval_callback, returning a typed ApprovalCallbackOutcome (NotApproval / Unauthorized / UnknownAction / Resolved). That puts the decision at a real, testable boundary instead of inline in the long-poll loop.
• A callback carrying no attributable from account fails closed, including under a wildcard allowlist — a new external surface defaults closed.
• An unlisted tap leaves the approval pending so the authorized operator can still decide it, and gets a localized refusal acknowledgement rather than a silent no-op.
• Scope boundary: Only the Telegram callback path. No change to how approvals are requested, to the approval broker, to other channels' approval surfaces, or to the allowlist semantics themselves. Binding an approval to the specific operator who triggered the turn (rather than to the channel allowlist) is a separate, larger change and is not attempted here.
• Blast radius: Telegram channel only. Non-approval callback payloads keep their existing behavior and return before any authorization work.
• Linked issue(s): N/A
• Labels: type:fix, risk:low, size:S

Testing (required)

How you can test

• Reviewer testing requested? Yes
• Interface(s) exercised: channel = telegram
• Setup / preconditions: A Telegram channel configured with allowed_users naming one account, and a second account in the same group chat that is not on that list. Trigger any tool call that requests approval so the inline keyboard is posted.
• Steps to run: From the second (unlisted) account, tap Approve on the prompt.
• Expected on this branch (after): The tap is refused with "You are not authorized to answer this approval", the approval stays pending, and the listed operator can still decide it.
• Prior behavior on master (before): The same tap resolves the approval and the tool call proceeds.

How I tested

Seven new tests at the decision boundary, written before the implementation (all failed with "method not found" first):

• callback_actor_identities_carry_username_and_numeric_id
• callback_actor_denied_when_from_is_absent — fail-closed under a wildcard allowlist
• callback_actor_denied_when_not_on_allowlist
• callback_actor_allowed_by_username_or_numeric_id
• unauthorized_tap_does_not_resolve_a_pending_approval — asserts the oneshot is unresolved and the approval is still pending
• authorized_tap_resolves_the_pending_approval
• unknown_action_from_an_allowed_actor_is_reported_not_resolved
• non_approval_callback_data_is_ignored_before_any_authz

cargo test -p zeroclaw-channels --lib telegram
# test result: ok. 223 passed; 0 failed; 1 ignored; 0 measured; 1133 filtered out

cargo fmt --all -- --check          # clean
cargo clippy -p zeroclaw-channels --all-targets -- -D warnings   # clean
bash scripts/ci/comment_hygiene_gate.sh   # Comment hygiene gate passed.

• CI checks relied on and why they cover this change: Rust quality gate covers the changed crate; the telegram test module is the behavior boundary for this path.
• Known CI coverage gap, if any: The long-poll listen() loop itself is not exercised end-to-end against a live Bot API; the extracted resolve_approval_callback is what the tests drive, and listen() is a thin dispatch over its outcome.
• Beyond CI, what did you manually verify? I verified the identity-extraction shape matches what the message paths already build (username normalized via normalize_identity, plus the numeric sender id). I did NOT run against a live Telegram bot.

Security & Privacy Impact (required)

• New permissions, capabilities, or file system access scope? No (it narrows an existing one)
• New external network calls? No
• Secrets / tokens / credentials handling changed? No
• PII, real identities, or personal data in diff, tests, fixtures, or docs? No — fixtures use alice / eve and synthetic numeric ids
• Prompt injection or untrusted model-visible text introduced/changed? No
• If any Yes, describe the risk and mitigation: N/A. This PR tightens an approval gate; the residual gap it does not close is that the check is allowlist-wide rather than bound to the specific operator who triggered the turn.

[JordanTheJet]

Note on the diff size. This branch is based on upstream/master (e91a7a0c6), but this fork's master is 313 commits behind upstream, so GitHub renders the base gap as ~1000 changed files. The real change is what the commit contains:

crates/zeroclaw-channels/src/telegram.rs   | 292 +++++++-----
crates/zeroclaw-runtime/locales/en/cli.ftl |   1 +
2 files changed, 251 insertions(+), 42 deletions(-)

Review with git diff upstream/master...fix/telegram-callback-approval-authz. Syncing this fork's master needs a decision first: merging upstream conflicts in 5 files, all fork-specific release/desktop CI (release-stable-manual.yml, tests/architecture/desktop_release.rs, tests/architecture/release_workflow.rs, tests/test_architecture.rs, apps/tauri/tests/capability_security.rs).