[pwei1018]

Summary

BC Notify sends are now archived after the provider's status callback arrives, not at send time. The PR also adds a shared E2E suite for the notify-api and notify-delivery services, and raises the Python minimum to 3.13.

Changes

BC Notify callback handling

• Send flow: after BC Notify accepts a send, delivery stores the provider response ID on the notification and marks it SENT. The notification and its content stay active.
• Callback endpoint: /api/v2/callback/ (role BC_NOTIFY_CALLBACK) stores every event in the new bc_notify_callback table.
  • A success or completed status marks the notification DELIVERED, writes NotificationHistory with the callback status and response ID, and deletes the active notification and content in one transaction.
  • Other statuses leave the notification in place.
• Stale sweep: find_archivable_notifications excludes BC Notify SENT rows, so they stay available for callback matching.
• Migrations:
  • 0016 adds bc_notify_callback.
  • 0017 renames the notify-history fields.
  • 0018 adds notify_response_id to notification.
• Docs: openapi.yaml and ARCHITECTURE.md are updated.
• Unit tests: added for the callback, models, notify service and delivery utils.

E2E suite (notify-service/e2e/)

The suite runs the real API and delivery apps in one process on a temporary SQLite database. Only Pub/Sub publish, the BC Notify HTTP call and smtplib.SMTP are faked.

• BC Notify success path: request, validation, publish, send, sending callback, completed callback, archived history, then lookup through the API. Also checks that an invalid recipient gets a 400 and nothing is published.
• SMTP success path: an HTML body with an <img> routes to SMTP. Delivery sends through the mocked server and archives the record as SENT.
• Resend: a stale FAILURE notification is republished by /api/v2/resend, sent by delivery and archived.
• Expired archive: a notification older than the archive window is moved to history as EXPIRED without being republished.
• Running: the suite works from either package's venv (uv run python -m pytest ../e2e) and is documented in both READMEs.

Python and dependencies

• Both packages are bumped to 6.0.0, require Python >=3.13, <3.14, and use ruff py313.
• Unit tests and the E2E suite pass on 3.13.13 for both services.
• uv.lock was regenerated for both. Each lockfile loses about 220 lines, so please look at those diffs closely.