User-scoped backup and restore within a system backup

[bcherrington]

Problem

A future TimeLocker experience should give each signed-in user a partitioned
view of the overall system backup. A user should be able to define selection
sets within their own access domain, inspect only the corresponding backup
content and metadata, and restore eligible files without access to the system
selection set, another user's partition, protected system content, repository
credentials, or unrestricted privileged operations.

This is a separate authorization model from Spec 009's system operator group.
Membership in a user partition must not grant system-backup status or control,
and system-operator access must not silently redefine a user's scoped partition.

Desired outcome

• Define a stable partition identity and ownership model for each user's access
  domain within a system-owned backup.
• Let users create, update, inspect, and remove selection sets only for files
  they are currently authorized to read.
• Present a partition-filtered snapshot view that does not disclose inaccessible
  paths, filenames, metadata, tags, hosts, selection names, or aggregate details
  from the system selection set or another user's partition.
• Let users restore only partition-visible content to destinations they are
  authorized to write, with safe conflict and overwrite handling.
• Revalidate access at backup, snapshot-list, and restore time so stale
  selections or changed group membership do not preserve access.
• Define behavior for symlinks, hard links, ACLs, ownership, groups, special
  files, mounts, path traversal, renamed paths, and deleted accounts.
• Ensure the privileged backend cannot be used as a confused deputy to read or
  overwrite another user or system path.
• Reuse Spec 009's versioned local contract, peer-identity authentication,
  locking, audit, and run-record seams while applying partition-specific
  authorization and redaction.
• Preserve administrator control over repository credentials, global schedules,
  retention, system selections, and recovery policy.

Required security properties

• A user can view or act on an item if and only if the operating system confirms
  that the user currently has the required access within that partition.
• Partition requests cannot name arbitrary executable paths, repository
  credentials, raw Restic arguments, or unrestricted filesystem paths.
• Snapshot and status responses reveal no protected system-selection or
  cross-partition metadata.
• Restores cannot escape an authorized destination through traversal, links,
  races, mount changes, or ownership manipulation.
• Authorization failures and partial operations produce secret-free audit and
  run records without leaking denied paths.

Out of scope for this issue

• General remote administration or a hosted control plane.
• Granting users direct repository credentials.
• Letting scoped users manage the system selection set, global schedules,
  retention, or protected recovery operations.
• Treating membership in Spec 009's system operator group as a user partition.
• Implementing the full desktop UI before the access-control contract is
  approved.

Acceptance planning

This issue is backlog and assignment authority only. Before implementation,
create a dedicated lifecycle spec covering threat modeling, identity,
authorization, partition and selection ownership, snapshot filtering, restore
destinations, time-of-check/time-of-use behavior, compatibility, tests,
migration, account removal, and operator recovery.