[codex] Revalidate workflow owners before webhooks

[jmecom]

What Changed

CallWebhook now reloads the workflow run and workflow row immediately before sending an outbound request, checks the workflow owner's current channel membership against Postgres, and denies the action if the owner has been removed. When that check fails, the workflow is disabled so later channel events do not keep scheduling the same outbound attempt.

This closes the workflow exfiltration path where a former private-channel member could leave behind a message_posted workflow and continue receiving future message contents through a public webhook.

Safety

The check is scoped through the run's community and workflow row, so it does not trust trigger input or the relay's membership cache. Channel-less workflows keep their existing behavior. Membership lookup failures fail closed: the webhook is not sent.

The regression coverage exercises both the allowed path for a current member and the denied path after removal, including the automatic workflow disable.

Testing

• cargo fmt --check
• cargo test -p buzz-workflow --lib
• cargo clippy -p buzz-relay --lib -- -D warnings
• env -u BUZZ_GIT_REPO_PATH cargo test -p buzz-relay --lib -- --test-threads=1

Not run:

• cargo test -p buzz-workflow --lib webhook_owner_membership_revalidation -- --ignored because local port 5432 is occupied by another project's Postgres and rejects the Buzz test credentials.