docs: Adding-a-Robot embodiment cookbook (closes #64)

[rylinjames]

Summary

Adds docs/adding_a_robot.md — step-by-step guide for adding a new embodiment to Reflex. Closes #64.

Adapted from #128

@DsThakurRawat opened #128 with the same goal. The doc structure (4-step process → two worked examples → common patterns by vertical → checklist) is theirs and good; preserved via Co-Authored-By on the commit.

What this PR fixes vs #128

#128's example JSONs used field names that don't exist in src/reflex/embodiments/schema.json. Anyone copy-pasting would have failed validation. Fixes:

#128 used	Schema actually requires
"labels": [...]	(no such field — action_dim is the structural signal)
"normalization": { "mean": [...], "std": [...] }	mean_action, std_action, mean_state, std_state (4 separate arrays)
Camera "width", "height", "encoding"	"resolution": [w, h], "color_space"
"workspace_bbox" (in constraints)	(not in schema — only max_ee_velocity, max_gripper_velocity, collision_check)

What I added beyond fixing

• Both example JSONs validated against the live schema + cross-field rules at PR time. A short Python snippet at the top of docs/adding_a_robot.md's Step 4 lets users do the same — it catches the most common mistake (wrong field names) before opening a PR.
• "Validate before opening a PR" section with a one-liner that exits 0 on success.
• Step 1 includes the new optional fields from feat(embodiments): quadcopter preset + optional gripper + payload_release #132: drones omit gripper + max_gripper_velocity and use payload_release instead. Example B (SkyScout, quadcopter) demonstrates this.
• Step 4 references reflex doctor + reflex go --dry-run as the end-to-end smoke test, not just unit tests.
• "Common patterns by vertical" section trimmed to verticals actually represented in the FastCrest customer research vault — warehouse AMR, farm/hobby (SO-100 class), aerial drone, smart-camera. Each pattern includes the actual reflex serve / reflex ros2-serve invocation.
• Drops the duplicate-file step. docs: create 'Adding a Robot' embodiment cookbook (closes #64) #128 instructed users to place the JSON in both src/reflex/embodiments/presets/ AND configs/embodiments/. The latter is a dev fallback that feat(embodiments): quadcopter preset + optional gripper + payload_release #132 deprecated; presets/ is canonical.

Validation pre-commit

[block 1] (myarm6)    ✓ valid (1 expected-enum violation — Step 3 fixes this)
[block 2] (quadcopter) ✓ valid (no errors, no warnings)
[block 3] skip (enum snippet, not a full config)

The "expected-enum violation" on block 1 (myarm6 slug) is the point — Step 3 of the cookbook teaches users to add new slugs to the schema enum. The validator correctly fails on a new slug pre-Step-3 and passes post-Step-3.

Closes / supersedes

• Closes [Docs] Create 'Adding a Robot' Tutorial (Embodiment Cookbook) #64 (the original good first issue)
• Supersedes docs: create 'Adding a Robot' embodiment cookbook (closes #64) #128 (closing with credit note)

Test plan

• Both example JSONs validated against validate_embodiment_config() from the live source
• Example A (myarm6) only fails on the expected embodiment enum violation (Step 3 territory); no field-name mistakes, no length mismatches, no out-of-range indices
• Example B (quadcopter) passes cleanly — uses the optional payload_release block + 10-DOF state matching /mavros/local_position/odom
• Cross-references match real files (schema.json, cli_reference.md, embodiment_schema.md, getting_started.md)
• Live preview (no docs site build wired in this repo — GitHub-rendered Markdown)