E44: a C++ program with no third-party libraries trains a policy on its own Pendulum

[tactino]

Stacked on #99 (E43). Merge that first. This diff then shrinks to experiments/e44-cpp-pendulum/ and one README table row.

E44 trains a policy through a C++ program with no third-party libraries. The program steps an environment of its own, and the Python env client is the control. PROTOCOL.md was pre-registered at 70f8cfd, after the pilot.

The client. pendulum_client.cpp:

• 867 lines; links only libstdc++, libm, libgcc and libc.
• Up to its WebSocket class it is plugrl-protocol's zero-dependency plugrl_client.cpp. After that it carries gymnasium's Pendulum-v1 written out in C++.
• equivalence.py checks the C++ Pendulum against gymnasium's, step for step: observations bit-identical, rewards within 1.2e-10, and the same time-limit step, across 20 trials of 200 steps.

The result (results/verdicts.txt). Every prediction holds. The run is gaussian-policy with ppo at rl-baselines3-zoo's Pendulum settings, 25 iterations of 4,096 steps, seeds 1-3.

• C++ client: -1,223/-1,172/-1,227 -> -251/-233/-275.
• Python env client: -1,191/-1,188/-1,259 -> -206/-264/-264.
• Both arms learn on 3 of 3 seeds (bar +500).
• The C++ seeds end inside the control's range widened by 150 (P4), which is the check on the C++ client's packing of the protocol.

What the pilot found:

• SPEC.md does not document info["episode"] (r, l, s, mask), which is the only thing the server's episode metrics read. A client written from the spec trained normally but logged a return of 0. The client now sends it as plugrl-env-client's wrapper does. A protocol PR to document it will follow.
• CleanRL's default PPO settings barely learn Pendulum in either arm. So the registered run uses rl-zoo's published Pendulum settings; the PROTOCOL declares the switch and why.

The control needs plugrl-env-client#10 (Classic-v1 continuous actions). The README's evidence row for "does an env client have to be Python" now cites E44, with E2 kept as the first C++ exchange.