fix(acp): admit trusted workflow wake messages

[matthewrball]

Summary

• Fix scheduled workflow messages being rejected by the owner-only ACP author gate because the relay, rather than the workflow owner, signs workflow output.
• Advertise the current workflow signer in NIP-11 and verify the workflow event signature and signer before attributing its first p tag as the owner.
• Refresh the trusted signer out of band and before reconnect replay; fail closed when the signer is unavailable or changes.
• Carry the verified workflow owner through subscription filters, setup-mode filters, prompt sender metadata, and human-aware reply anchoring instead of exposing the relay signer downstream.
• Preserve the owner as the first workflow-output p tag while keeping mentioned-agent wake targets.

Validation

At c98ca6a:

• cargo fmt --all -- --check
• cargo clippy -p buzz-acp --all-targets --all-features -- -D warnings
• cargo test -p buzz-acp: 623 unit tests and 9 lifecycle tests passed; doc tests passed.
• Independent security review completed with no findings.

At e46802e before the ACP-only follow-up:

• cargo clippy -p buzz-acp -p buzz-relay --all-targets --all-features -- -D warnings
• cargo test -p buzz-relay nip11::tests --lib: 15 passed.
• cargo test -p buzz-relay workflow_sink::tests --lib: 18 passed.
• Repository targets test-unit, desktop-test, desktop-build, desktop-tauri-check, desktop-tauri-test, and web-build passed.

Known unrelated validation gaps

• just ci reaches mobile analysis, where Flutter 3.44 reports the existing axisAlignment deprecation in mobile/lib/features/pairing/pairing_page/pairing_welcome_view.dart:114.
• The mobile test suite reports four existing widget-test failures under Flutter 3.44; this branch does not touch mobile code.
• The full buzz-relay suite and isolated pre-existing admin/media database tests hit Sqlx(PoolTimedOut) in the local database environment. The changed relay modules pass their focused tests.

[matthewrball]

@block/buzz-oss-team Ready for review. This unblocks scheduled owner-scoped agent workflows that are currently dropped by the ACP author gate. All GitHub checks and the local ACP/relay validation in the PR description are green; the trust path fails closed for a missing or mismatched workflow signer. A security-focused review would be appreciated.

[matthewrball]

Follow-up commit c98ca6a closes a downstream attribution gap found during independent review: subscription filters, setup-mode filters, prompt sender metadata, and human-aware reply anchoring now receive the verified workflow owner rather than the relay signer.

Fresh validation at this commit:

• cargo test -p buzz-acp: 623 unit tests and 9 lifecycle tests passed
• cargo clippy -p buzz-acp --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check
• Independent re-review: no correctness or security findings

[shanemhamilton]

Additional field evidence for the prompt-attribution part of this PR, beyond whether a workflow wakes the agent:

Verified in Buzz Desktop 0.5.25 on macOS, September 30, 2026, at 11:41 AM America/Chicago. A scheduled workflow successfully started the managed agent, but its visible Prompt Context event block presented the relay identity in From: with no explicit verified workflow-owner provenance in the displayed sender metadata. The agent then said the sender did not match its human owner and ran three additional tool calls to investigate authority (including a redundant membership command after using a CLI flag in the wrong position).

It eventually proceeded, reasoning that the buzz:workflow:true tag established that it was a scheduled trigger. That conclusion must not be the trust contract: a marker alone is forgeable, and membership/file timestamps are not cryptographic provenance.

Current source already has a stronger author-gate check in verified_workflow_owner: event signature, active relay NIP-11 signing identity, canonical workflow-owner attribution, and an explicit target mention. The remaining requirement is to carry that verified result through batching and into the model-visible prompt, rather than making the model reconstruct provenance from raw event metadata.

Suggested acceptance criteria:

• The prompt explicitly distinguishes the transport signer from the verified workflow owner, and identifies the workflow/run when trustworthy identifiers are available.
• The trusted provenance is generated by the harness from verification results; user content or workflow tags alone cannot populate it.
• Verified owner-created workflow instructions use the owner's existing authorization scope. This does not widen authority or bypass action-specific approvals.
• Regression coverage follows the real admission -> batch -> prompt path and covers both a legitimate owner workflow and forged/unverified attribution.
• A workflow run can begin without a model-driven sender-membership lookup solely to determine who authorized it. Reading a task's required guide remains normal work.

This is UI/source inspection evidence, not a passing integration-test claim. No agent permissions, prompts, or running workflows were changed. Related: #3858.