Harden file:// store object-key confinement

[amazon7737]

Context

The file:// store backend currently joins caller-provided object keys to the configured root for uploads and reads. The backend contract should reject absolute paths and lexical traversal instead of relying on every caller to construct a safe key.

Acceptance criteria

• Validate object keys before Upload, UploadData, and Get touch the filesystem.
• Reject absolute paths, empty or root-like keys, and keys that escape through .. or platform-specific separators.
• Preserve current behavior for valid keys such as sessions/<id>/manifest.json and sessions/<id>/redacted.jsonl.
• Add synthetic tests proving rejected keys cannot read or write outside the configured store root.
• Keep user-facing errors actionable and in English.
• Pass targeted race tests and the repository-wide validation suite.

First safe step

Add table-driven synthetic confinement tests around the fileStore backend before changing its path resolution.

Non-goals

• Changing S3 key semantics.
• Reading real transcripts, manifests, credentials, or user home output.
• Deployment or destructive filesystem migration.