Guard against unwritable root-owned jobs/ directories

[dbroeglin]

Why

Running a freshly scaffolded experiment can fail with a bare PermissionError: [Errno 13] Permission denied: '.../jobs/<job-name>'.

The Pier Docker backend runs task containers as root and bind-mounts the jobs/ directory, so a completed run can leave jobs/ (and its contents) owned by root. A subsequent run started as your normal user can no longer create a new run directory under it, and Pier surfaces only an opaque PermissionError with no hint at the cause or the fix.

What

• Add check_jobs_dir_writable() in pier_backend.py. It resolves the run directory Pier will create (jobs/<job-name>[/<run-id>]), walks up to the nearest existing ancestor, and raises PierBackendPreflightError with an actionable sudo chown -R "$(id -u):$(id -g)" <dir> (or rm -rf) remediation when that ancestor is not writable.
• Wire it into _validate_pier_specs, so both validate and run report a clear jobs dir check and fail fast instead of crashing mid-run.
• Document the failure mode and remediation in the scaffold README.md.tmpl (new Troubleshooting section) and in docs/collecting-run-data.md.

Notes

• The writability probe is injectable (writable=) so tests stay offline and do not depend on real uid/permissions (CI often runs as root, where a real chmod-based probe would misbehave).
• Pier has no container-user remapping knob, so root-owned output can recur; this guard turns the resulting crash into a clear, fixable message.

Testing

• uv run ruff check . and uv run ruff format --check . clean.
• uv run pytest -q green, including three new tests covering the writable case, the nearest-existing-ancestor remediation message, and the CLI surfacing the jobs dir check.