fixup! Implement tiered storage

Refine TierStore backup semantics

In this commit, we rework TierStore backup persistence away from the
previous best-effort, background-queued model and make backup writes/
removals part of the foreground success path.

This changes the persistence contract when a backup store is configured:
writes and removals for primary-backed data are now issued to the primary
and backup stores concurrently and only return success once both complete
successfully. This changes TierStore's persistence guarantee to include
both the primary and backup stores: when a backup store is configured,
writes and removals only succeed once both stores have completed successfully,
instead of treating backup persistence as best-effort.

As part of this change:
- remove the backup queue, sender, and background worker machinery
- remove best-effort queueing behavior and the associated logging paths
- simplify `set_backup_store` to pure configuration
- implement concurrent primary/backup write and remove helpers
- propagate backup failures to the caller instead of silently logging them
- document that dual-store operations are not atomic across stores, so an
  error may be returned after one store has already been updated
- clarify that the backup store is not used for reads or lists during normal
  operation
- tighten `set_ephemeral_store` and TierStore field/type documentation to
  better explain storage roles and guarantees

Update unit and integration tests to match the new synchronous backup
behavior:
- replace delay-based backup tests with assertions that backup writes and
  removals are part of the immediate success path
- strengthen the tier-store integration test to compare concrete primary and
  backup artifacts instead of checking that backup is merely non-empty
- add negative assertions showing that ephemeral-routed data is not mirrored
  to primary or backup stores

Author: enigbe