docs: E11 on the home page, and the pi0 examples that could not run

[tactino]

Three changes, all from E11.

The home page now says a VLA ran through this

A section after Verify, in both languages. The same two processes carry a
full-size pi0.5. As a control, the unmodified checkpoint scored 99 of 100
on libero_spatial and 185 of 200 on libero_10 - openpi publishes 98.8
and 92.4 - and the server's episode and step counts matched the clients' to the
unit, which is the part that says the transport dropped nothing.

The section then says the reinforcement learning result is negative: one
FPO iteration took the hardest task from 26 of 50 to 0 of 50, and the run is
incomplete at one iteration of ten, because a second learn step does not fit
beside the optimizer state the first one allocates on a 24 GB card. The
predictions were pre-registered and one of them is falsified. A reader who
follows the link finds the same thing said at greater length, not a better
version of it.

The LIBERO page now says how E11 drove it

The evaluation invocation, copied from e11_stageA.sh as it was committed, and
the three flags whose absence quietly changes what you measure:

• --runner.pass-proc-id gives process i task i, which also makes
  --num-episodes a per-task count rather than a total.
• --recorder.no-thread0-only makes every process write its own
  summary.json. Without it only process 0 reports and per-task success rates
  cannot be recovered afterwards.
• Rendering needs MUJOCO_GL=egl, and the GPU it renders on follows EGL's own
  device order, which need not agree with CUDA_VISIBLE_DEVICES.

Plus the one-line difference that turns the ten-task sweep into the single-task
setup the fine-tuning runs used.

The pi0 examples could not have run

docs/policy/index.md, docs/policy/dppo_policy.md and their Chinese
counterparts all carried a variant of:

plugrl-run-server pi0-policy default dppo hopper --policy.checkpoint_path /path/to/checkpoint

Three independent reasons it fails:

• pi0-policy is a flow policy. It pairs with fpo or eval. dppo
  expects a diffusion policy.
• hopper is one of dppo's presets, passed here as the algorithm config
  for an algorithm that is not being used.
• The flags use underscores. The CLI generates --policy.checkpoint-path,
  --policy.denoising-steps, --exp-name.

They are replaced by the eval and fpo invocations E11 ran, with
pi05_libero rather than pi05_tiny_libero as the config name, since that is
the one that was actually run. The same fix landed in the server README
(PlugRL/plugrl-server#23).

One judgment call worth reviewing

The DPPO page spelled its own flags with underscores too - --exp_name,
--policy.env_type, --policy.env_name, --policy.checkpoint_path. I
hyphenated them. --exp-name is verified: it appears in the harness scripts of
a run that worked. The dppo-policy ones are not - the dppo extra is not
installed on this machine, so I have not run them. Hyphenating them asserts
nothing new about whether those fields exist; it only applies a CLI-wide rule
that is already verified. If a field name there is wrong, it was wrong before
this PR too, and someone with the extra installed should check.

Checks

• The three success rates are read from E11's results/stageA.tsv and
  results/stageC_eval.tsv, not from memory.
• Every command is copied from the committed harness scripts, not
  reconstructed.
• mkdocs build --strict passes; both en and zh build.

🤖 Generated with Claude Code