feat(canopy): N2: blob store backups and paired restore

[dannash100]

Implements the bestool side of Tamanu's blob store backup spec (specs/blob-storage/backups.md, id BKUP, on beyondessential/tamanu#10708). The store is a content-addressed, append-only tree, so a tamanu-postgres backup alone no longer captures a server's whole state, and the two captures have to stay ordered (database first, store second) and be restorable as a pair. Continues from #809.

Stacked on #854, which carries the follower mechanism (after, paired restore, shared volume captures) on its own so it can land without waiting on blob QA. Review this one against that base; it is now blob-only:

• [simple] accepts path_command as an alternative to path, and bestool tamanu blob-root prints the store root from Tamanu's blobStorage.root setting, so the def follows an admin-panel change instead of silently going stale, and a restored store lands where the just-restored database expects it.
• The blob store def then follows tamanu-postgres using feat(canopy): chain follower backups and restore them as a pair #854's after.

Checked on a real repo against the pinned kopia 0.23.1: both pairing signals come back from snapshot list. Tags looked like they didn't because the key comes back spelled tag:canopy-type.

USAGE.md was regenerated on macOS without the iti features and spliced by hand; the check-docs job is the byte-for-byte confirmation.

[dannash100]

🤖 No Canopy code change. BackupType is open (Custom(String)), staleness and alert refs are already per (server, type), and restore credentials are issued per (server, type).

One config step, and it's required rather than optional: crates/database/src/backup/staleness.rs only scans types with a non-NULL expected_interval, and a newly-seen type arrives with none. A follower-only blob type would never alert, so a chain that stops leaves the store unbacked and silent.

On Canopy, once the type name is final:

1. Backup defaults screen, "Add a backup type", enter the name.
2. Give it an interval, longer than the postgres one. The chain covers the common case; the scheduled run adds a capture on top, cheap under dedup but not free.
3. Set retention.
4. Set auto_enable, or leave it off and enable the capability per group on the group's backup page.
5. Per-group interval override on that page if a group needs a different cadence.

No migration, no PR.

[passcod]

I think it does need something from canopy, because canopy won't allow the creds for the followers

[dannash100]

🤖 You're right, and my comment above is wrong on that. require_backupable_capability (crates/public-server/src/backup.rs:110) needs the type to be an enabled capability on the server, and a newly-registered type seeds enabled from that type's auto_enable, which is false when no backup_type_defaults row exists. So by default every follower run 409s at issuance.

Still config rather than code, but with an ordering constraint: the type default has to exist, with auto_enable = true, before the follower def ships. register only seeds on insert (crates/database/src/backups.rs:546), so if devices register the type first, the capability rows land disabled and setting the default afterwards doesn't touch them, leaving a per-server flip.

Enabling can't be coded away regardless, since the staleness scan filters on enabled too.

If the ordering risk is worth code, the smallest version is an operator-set flag on the capability so register re-seeds from the current default while it's unset. Own canopy PR, helps any future type. Teaching canopy the chain instead is bigger and means enabling postgres implicitly authorises blob uploads, which is what the per-type gate is there to prevent.

Also correcting the comment above: restore creds aren't gated per type, only by the per-server restore window.

[passcod]

Generally LGTM, one thing that could be a nice optimisation if not already considered is on systems where snapshots are whole-volume (NTFS), and where both leader and follower (etc) are on the same volume, take a single snapshot to run both backups.

[passcod]

Well, kind of: if /var/lib/foo is a btrfs subvol, and we try to backup /var/lib/foo/bar and /var/lib/foo/qux, that's still shared snapshot coverage

[dannash100]

Splitting some of this out so I can separate secret backup from blob backup