fix: resolve OPENPI_ROOT before guard; document single-GPU run and local-weight env vars

[memosr]

Summary

Three fixes that block a fresh clone from following the README end to end.

1. training/run_libero_eval.sh fails with the default OPENPI_ROOT

The -x guard for the LIBERO venv runs before the cd into OPENPI_ROOT.
With the README's own relative default (third_party/openpi), the guard passes
against the wrong path and the script then fails at exec:

line 20: third_party/openpi/examples/libero/.venv/bin/python: No such file or directory

Fix: resolve OPENPI_ROOT to an absolute path with cd … && pwd before the
guard. PYTHONPATH inherits the resolved value. The other three scripts in
training/ are unaffected, since they build relative paths after the cd.

Verified against a stub OpenPI tree: relative default now exits 0 with a correct
absolute PYTHONPATH; absolute OPENPI_ROOT, missing checkout (exit 2) and
missing venv (exit 2) all behave as before. The missing-venv diagnostic now
prints the resolved path instead of a misleading relative one.

2. README Quick Start requires ≥4 GPUs

The patched config sets fsdp_devices=4, batch_size=8, so the documented
command needs four GPUs. The only successful run recorded in blocker.md:19
used a single GPU with CUDA_VISIBLE_DEVICES=0,
XLA_PYTHON_CLIENT_PREALLOCATE=false, batch size 1 and local checkpoints —
none of which appear in the README.

The existing command is kept verbatim under a Multi-GPU heading with its
requirement stated; a Single GPU variant is added below it.

3. Local-weight env vars are undocumented

AXIS_PI05_DROID_ASSETS, AXIS_PI05_LORA_INIT_PARAMS,
AXIS_PI05_FULL_INIT_PARAMS and the LIBERO_PI05_* pair all default to
gs://openpi-assets/.... Unset, they silently require GCS egress and
credentials. Added as a table in a new section, with defaults read from the
patch rather than inferred.

Scope

No changes to pyproject.toml, environment.yml, tests/ or CI, to avoid
overlapping with #1.

Needs maintainer confirmation

The single-GPU block passes --batch-size 1 --fsdp-devices 1 as tyro overrides
on TrainConfig, following the precedent of --num-train-steps and
--checkpoint-base-dir already in the README (all forwarded via
run_train_openpi.sh:59). I could not run real training to confirm those two
flag names resolve. Please verify before merging.

Out of scope, flagged for awareness

Issue creation is disabled on this repo, so noting here rather than filing:

• No LICENSE. A public repo without one is all-rights-reserved by default,
  which blocks downstream use. Licensing is the copyright holder's call, so I
  did not submit a file.
• convert_dataset calibrates the gripper per parquet shard. With the
  shipped auto_q99/auto_q01 defaults, identical physical finger openings map
  to different normalized values depending on which shard a frame lands in.
  The open_width/clip_rate written to meta/…report.json come from a global
  fit, so the report does not describe the emitted data. Changing this alters
  output semantics, so it needs a maintainer decision.
• blocker.md B003 is marked fixed but changed nothing in the repo — it
  records a one-off workaround. Evidence for B003/B004/B005 points at
  reports/*.log, which .gitignore:10 excludes and which is not present; the
  referenced commit 3440bf85 is not in this repo's history (single commit
  4ffc886). None of it is independently verifiable.

[memosr]

One more note for the "out of scope" list, related to the single-GPU section in this PR.

training/run_train_openpi.sh:24 sets:

export XLA_PYTHON_CLIENT_MEM_FRACTION="${XLA_PYTHON_CLIENT_MEM_FRACTION:-0.9}"

This is a default, not a forced value, so it can be overridden from the caller's
environment. But the 0.9 default is undocumented, and it is the same
preallocation behaviour that produced the OOM recorded in blocker.md B005
(RESOURCE_EXHAUSTED, XLA reporting it could only reduce to 37.48 GiB while
GPU0 had ~4.35 GiB free). On a shared node, an unaware user following the
Quick Start hits this immediately.

The single-GPU block added in this PR sidesteps it with
XLA_PYTHON_CLIENT_PREALLOCATE=false, which makes the fraction moot. So this
PR is not blocked on it.

Two possible follow-ups, both maintainer calls, which is why they are not in
this diff:

1. Document the 0.9 default and when to override it.
2. Lower the default, or skip it when XLA_PYTHON_CLIENT_PREALLOCATE=false is
   set.

Happy to send either as a separate PR if you have a preference.