feat(secrets): AAD-bind email-trigger inbound secrets v0->v1 (Track A M3)

email_trigger_details.inbound_secret_encrypted was sealed v0 (no AAD, bound only
to the master key) because the table had no version column — a ciphertext could
in principle be relocated between rows (audit 2026-06-11 H-D1, Medium). Bring the
AAD versioning the `secrets` table gained in 0042 to email secrets.

- Migration 0069: `email_trigger_details.inbound_secret_version SMALLINT DEFAULT 0`.
- secrets_service: `seal_email`/`open_email` seal v1 with AAD bound to the
  SEALING OWNER (`email:{app}` / `email:group:{group}`) — deliberately NOT the
  per-row trigger_id, so a group template's sealed bytes stay valid when the
  materializer copies them verbatim to each descendant (all share the group AAD).
  v0 rows keep their exact legacy no-AAD read path.
- Both email-trigger create paths (declarative apply resolve_and_seal +
  triggers_api create_email_trigger) seal v1 under the trigger's owner; the
  version threads through CreateEmailTrigger + insert_email_trigger_tx.
- materialize copies inbound_secret_version verbatim with the bytes.
- email_inbound_target recovers the sealing owner (materialized_from ->
  template.group_id, else the app) so receive_inbound_email opens a v1 secret
  under the right AAD.

Cross-app/tenant relocation now fails the GCM tag; a same-owner swap is not
distinguished (accepted low-severity residual). Pinned by
email_secret_aad::materialized_email_copy_decrypts_under_the_group_aad (the
novel materialized-copy path) + the extended secret_round_trips_through_seal_open
lib test. Schema golden reblessed; materialization + email e2e regressions green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/manager-core/src/materialize.rs

@@ -226,14 +226,17 @@ async fn materialize_one(
         "email" => {
             // §M5.5: the group template sealed its inbound HMAC secret against
             // the GROUP's own store once at apply (shared-group-secret model).
-            // The secret is v0 (no AAD) — bound only to the master key, not the
-            // owning row — so a verbatim byte-copy is a valid per-app secret; no
-            // master key is needed here. Each copy has its own trigger_id (its
-            // own inbound webhook URL).
+            // The secret's AAD (§M5.5 / audit H-D1) is bound to the GROUP owner,
+            // NOT this copy's row, so a verbatim byte-copy stays openable — the
+            // inbound path recovers the group via `materialized_from`. Copy the
+            // version verbatim too. Each copy has its own trigger_id (its own
+            // inbound webhook URL).
             sqlx::query(
                 "INSERT INTO email_trigger_details \
-                    (trigger_id, inbound_secret_encrypted, inbound_secret_nonce) \
-                 SELECT $1, inbound_secret_encrypted, inbound_secret_nonce \
+                    (trigger_id, inbound_secret_encrypted, inbound_secret_nonce, \
+                     inbound_secret_version) \
+                 SELECT $1, inbound_secret_encrypted, inbound_secret_nonce, \
+                        inbound_secret_version \
                  FROM email_trigger_details WHERE trigger_id = $2",
             )
             .bind(new_id.0)