fix(ansible): move pgBackRest spool-path off the 10GB root volume

[hunleyd]

Summary

pgBackRest's spool-path was never set explicitly, so it defaulted to /var/spool/pgbackrest on the AMI's 10GB root volume instead of /data (the dedicated EBS volume PGDATA lives on). This PR sets spool-path = /data/pgbackrest_spool in the ansible-managed pgbackrest.conf and updates the AppArmor profile to allow writes there, so archive-push/archive-get transient data survives events (pause/restore, pg_upgrade, resize-compute) that wipe the root volume.

---

Details

• Sets spool-path = /data/pgbackrest_spool in the ansible-managed [global] pgbackrest.conf, and updates the directory-creation task to create that path instead.
• Updates the sbpostgres AppArmor profile (postgres_shell and pgbackrest_shell sub-profiles) to grant write access to /data/pgbackrest_spool instead of the old /var/spool/pgbackrest. The profile runs in enforce mode, so without this change the config change alone would just trade "spool fills the root volume" for "every archive-push/archive-get write gets denied."
• /data is the volume that survives pause/restore, pg_upgrade, resize-compute, and restore-to-new-project. Those events can discard the existing EC2 instance and its root volume, so anything written there is lost.
• This is a [global]-scope pgBackRest option, set once at provisioning. No supabase-admin-agent changes needed. Split out of feat(sudoers): let supabase-admin-agent invoke pgbackrest reconcile as root #2291 (sudoers grant for pgbackrest reconcile) since the two are unrelated concerns: one is a privilege-escalation grant, this one is a storage-location fix, and neither depends on the other.

Why this is safe

• pgBackRest's own documentation recommends spool-path live on the same filesystem as pg_wal, so archive-get can hand a WAL segment to Postgres with a rename instead of a copy. /data/pgdata/pg_wal is on /data, so this change satisfies that recommendation directly. That's the primary justification.
  • Secondary: the old /var/spool/pgbackrest also shared the 10GB root volume with the OS, systemd, and journal, so headroom there was already thin; moving off it removes one more consumer of that shared space. This trades that exposure for the spool queue now sharing /data with PGDATA instead: a smaller volume of contention (pgBackRest's archive-get-queue-max defaults to a bounded 128MiB), but worth naming as the tradeoff being accepted rather than a pure win.
• Spool-path data is disposable. Per pgBackRest docs, spool-path contents aren't durable state. archive-push rechecks each WAL segment against the repo and archive-get rebuilds its queue on loss. No migration needed for spool contents.
• Matches the existing ownership pattern (pgbackrest:postgres) already applied to every other entry in the same directory-creation loop.

Known gap (tracked separately, not blocking this PR)

• The directory-creation task above only runs at AMI-bake time. /data itself is root:root 0755, so an instance whose /data volume didn't come fresh from this AMI's own data snapshot (resize-compute, hibernation-resume, pg major upgrade) never gets /data/pgbackrest_spool created, and the unprivileged pgbackrest user can't self-create it there.
  • Companion fix: supabase-admin-agent's reconcile command already backfills this via EnsureSpoolDir() (supabase-admin-agent#120, currently draft pending its own dependencies). It runs every ~10 minutes via the existing Salt cycle, the same mechanism this codebase already uses to close AMI-provisioning gaps on the live fleet.
• This is latent today because pgBackRest isn't fleet-deployed yet and archive-async is off everywhere (INDATA-996 is the fleet-wide enablement gate). supabase-admin-agent#120 needs to land before INDATA-996 ships fleet-wide, not before this PR merges.
• The sbpostgres AppArmor profile duplicates its file-permission rules between the postgres_shell and pgbackrest_shell sub-profiles (pre-existing, not introduced by this PR), tracked as INDATA-1180 for a future #include-based dedup.

---

Testing

• ansible-playbook --syntax-check passes cleanly on the full playbook
• Manual: confirm /data/pgbackrest_spool exists with pgbackrest:postgres ownership after provisioning, and archive-get/archive-push operate against it under the updated AppArmor profile

---

Misc

Resolves INDATA-1038

Internal-only entry: supabase/changelog#225

[brainrake]

Looks good. Will need to make sure it migrates correctly on existing instances. I think we need to move the directory if it exists. It depends on how/when pg_backrest is run and what is in the directory.