[X-F-R]

Summary

Follow-up to the onboarding walkthrough in #18, which already covers the quick start, the
install steps and the serial permissions. This is the part that walkthrough did not reach.

Base is docs/fix-new-user-onboarding so the diff shows only these changes. The diff
against main includes #18 as well.

The blocking one: TROUBLESHOOTING.md:144 says a cartesian move from the fully-extended
home pose "always" fails with err=1. Measured on hardware, a 1-4 mm step is
accepted and reconstructs the arm by 13-60 deg while the tool moves 1-3 mm. The gate
catches large steps, not small ones, so "always" sends the reader the wrong way about the
one pose that is actually dangerous. Same finding as #19 §1.

examples/03_move_p.py described its default as "a small step you can step back
from". From the zero pose the same 1 cm target reconstructs the arm by 86.88 deg
(J1 74 deg, J3 52 deg) and the script still prints move_p 到位. The mechanism is on the
firmware side and the example cannot fix it: move_p reaches the bus through
kin_runner_request_move_p (kin_runner.c:196), which has no adjacent-solution gate at
all, while move_l / move_c / move_path go through cart_plan.c:1029 and reject a
jump beyond CART_MAX_IK_STEP = 0.35 rad. At a healthy pose the same call is 5 deg of
motion, so this is "do not start from the singularity", not "move_p is broken".

Changes

• TROUBLESHOOTING.md, TROUBLESHOOTING.zh-CN.md — replace the "always" claim with the
  measured boundary, and add the measured ratio as a discriminator.
• docs/DEVELOPER_GUIDE.md, docs/DEVELOPER_GUIDE.zh-CN.md — §5.1 and §5.3:
  • wait=False skips only the wait for the arm to settle. Both values block for the
    plan reply, so poll_cart() never yields a result from one; its real use is
    recovering a call whose ACK timed out. cart._request_and_wait calls _cart.wait
    unconditionally, which confirms it.
  • enable() returns before the state stream reflects it: 2.0-2.7 ms to return
    against 7.0-7.8 ms for get_state().enabled to turn true, so reading it on the
    next line always shows False.
• src/litearm/arm.py — the enable() docstring carries the same measurement. This is
  the only source change in this PR; it is a docstring, not behaviour.
• README.md, README.zh-CN.md — the API reference cartesian snippet used three
  absolute poses with rpy = (pi, 0, 0). That orientation solves only about half the
  time in a 135-pose sweep (51-53% against 100% for (0, 0, pi)); the snippet now
  offsets the measured pose. (The quick start and install sections are docs: fix the onboarding gaps found by a new-user walkthrough #18's, untouched
  here.)
• examples/03_move_p.py — docstring corrected; the example bends a joint before
  issuing move_p.
• examples/06_cartesian.py — same first step. From the zero pose all three of its
  cartesian entry points are refused (err=1): safe, but the example never ran.

Testing

Documentation and two example scripts, plus one docstring.

$ LITEARM_LIVE=1 python3 -m pytest -q
3 failed, 657 passed

The 3 failures are pre-existing on main and unrelated to this PR:
test_every_firmware_literal_err_code_is_registered,
test_symbolic_site_manifest_matches_firmware,
test_bench_model_axis_matches_sdk_constant. They need a litearm-stm32 checkout to run
at all, and #21 fixes them.

Both examples and the revised snippet run against the arm:

$ python3 examples/03_move_p.py --go        -> EXIT=0
$ python3 examples/06_cartesian.py --go     -> EXIT=0  (n_wp 5 / 7 / 9 / 6)

Issues

Refs #19 — the TROUBLESHOOTING.md:144 half of that report. The other half (overlapping
cartesian commands losing replies) is untouched: it is firmware-side and this PR does not
address it.