Apply the retention clock to the Google Drive archive

[tytremblay]

The monthly archive in the team's Google Drive holds the same recorded messages as the SQLite log, so docs/consent-form.md's deletion promise covers both copies. Deleting from the database alone leaves the archive as an undeleted second copy.

Automated retention rules in Drive need Google Vault, which is not in the base Workspace for Nonprofits tier. Two options:

1. Manage it from hawk-mod via Drive API calls — delete archive objects past the clock alongside the database purge.
2. Leave it as a documented annual manual task with a named owner in the runbook.

Option 1 is the plan of record. Depends on the bulk export and the purge job.

Access-control note: the form states that only the two screened Slack administrators can read recorded messages. That stays true only while the Drive folder's permissions — and the Workspace super admins — are those same people. Worth an assertion in the runbook.

[tytremblay]

Reshaped by the design session recorded in docs/adr/0001-metadata-exports-and-encrypted-snapshots.md.

There will be no readable archive of recorded messages in Drive, so the retention clock has a much smaller target there. The only content copy in Drive is the encrypted snapshot, and the export job keeps only the newest three — retention for that copy is pruning on a schedule rather than per-conversation deletion, and needs no Vault.

What survives from this issue:

• Option 1 (manage it from hawk-mod) is still the plan, and is largely implemented by the snapshot-retention rule.
• The access-control note stands and gets sharper: the export folder is created by hawk-mod in the authorizing administrator’ s Drive, and its sharing is still the access control on the content-blind exports. Snapshots are unreadable without the offline key, so the folder’ s permissions no longer gate message content.
• The remaining dependency on issue Purge records past the retention period #3 is just the database side.

The runbook assertion should now cover two things: who can read the export folder, and where the snapshot decryption key is held.