WIP: patchwork: enhance integration

[derekbarbosa]

THIS PR IS A WORK IN PROGRESS

This PR adds patchwork integration to sashiko, allowing
subsystem maintainers to report review results as patchwork checks
either through direct API calls or email notifications.

Patchwork's permission model is coarse: an API token that can post
checks can also change patch states and perform maintainer operations. Some
subsystems (like linux-media) are not comfortable giving sashiko a write token
with that scope. While there are PRs open to change this behavior, they are
still pending, and we would ultimately prefer to give developers the choice to
opt-in to either-or-both, anyway.

This PR provides two modes so each subsystem can choose the integration that
fits their security posture:

• API integration for subsystems that accept the token risk in exchange for
  direct, low-latency check delivery

• Emails for subsystems that prefer sashiko to send a structured email that a
  local script (like pw_tools) parses and posts using the maintainer's own
  credentials

The following is an LLM-assisted summary of the changes in the proposed PR:

Config (email_policy.rs):

• New patchwork.email field for email integration
• SASHIKO_PATCHWORK_TOKEN env var (in lieu of .toml config)
• URL normalization on load

Schema (schema.sql):

• New patchwork_outbox table for retry-queued API check delivery

Runtime (patchwork.rs, worker/patchwork.rs, reviewer.rs):

• PatchworkWorker polls the outbox, posts checks, retries on failure and
  reclaims ghost entries after 10 minutes
• Reviewer inserts into the appropriate outbox(es) instead of fire-and-forget
  tokio::spawn
• post_patchwork_check() refactored to return Result, accept a shared
  reqwest::Client, URL-encode message-IDs, and warn on ambiguous multi-patch
  results

Database (db.rs):

• EmailOutboxRow.patch_id changed from i64 to Option to match the schema
  which allows NULL. Required for patchwork email notifications that use
  patch_id = NULL to avoid the dedup guard.

Patchwork API interaction

Two endpoints, executed sequentially by the PatchworkWorker: 1. GET
{api_url}/patches/?msgid={encoded_msgid}

• resolve the email message-ID to a patchwork patch ID

2. POST {api_url}/patches/{patch_id}/checks/

• submit the check result (state, description, target_url, context)

Email mode skips both endpoints. It sends a parseable plain-text email that a
downstream tool converts into these same API calls using the maintainer's own
token.

Design tradeoffs

Separate patchwork_outbox table over extending email_outbox with extra columns.
Different semantics (retry with backoff vs one-shot), different columns, cleaner
separation.

Email mode reuses email_outbox with NULL patch_id over a separate table for
patchwork emails. Reuses the existing EmailWorker and SMTP infrastructure; no
new worker needed for email delivery.

Env var fills token gaps, does not overwrite over always overriding TOML.
Preserves per-subsystem token differentiation when maintainers configure
different tokens per patchwork instance.

Worker backoff blocks the loop over scheduled retry with future timestamps.
Simpler; expected volume is low; if patchwork is down, all entries to that
server fail anyway.

Unconditional worker startup over starting only when config has patchwork
enabled. Config is reloaded per-notification, so a startup-time check would miss
later enablement.

Known limitations

• No SSRF protection on api_url -- pre-existing. Threat model assumes trusted
  config file authors. We add scheme validation (http/https only) but no host
  filtering.
• Patchwork permissions scope unresolved -- upstream limitation. Email mode
  exists as the mitigation for subsystems that can't accept the broad token
  scope.
• No integration test for PatchworkWorker -- requires mock HTTP server. Deferred
  to manual validation against a real patchwork instance. Unit tests cover all
  components individually.
• Worker backoff blocks all entries -- acceptable at current volume. Would need
  a scheduling queue under high throughput.

Pre-existing issues fixed opportunistically

1. EmailOutboxRow.patch_id type mismatch (i64 vs nullable schema)
2. Message-ID not URL-encoded in patchwork API queries
3. Multiple patches for same msgid silently used first without warning

fixes: #252

THIS PR IS A WORK IN PROGRESS