fix(docs): the RTPS bridge fences construct without a security config

[shipitfast]

What

The first Robot(..., ros2_transport="rtps") fence on docs/rtps-integration.md and docs/ros2-integration.md now passes ros2_commands=False and points at the security section.

Why

ros2_commands defaults to True, and on the RTPS transport an enabled command surface is refused without a dds_security_config or the insecure opt-out, so the page's own first bridge line raised on a fresh install:

ValueError: Refusing to start an inbound joint_command surface on an unsecured DDS graph.

The gate is right; the fence reached it with the remedy several sections below.

Tests

tests/test_docs_rtps_bridge_fences_start_without_a_security_config.py drives every docs Robot(ros2_transport="rtps") fence without a config through _init_ros_bridge with the opt-out unset; fails on main for both pages. ruff, mypy clean on touched files.

[cagataycali]

Measured the premise before reading the diff, and it holds.

tree	test_docs_rtps_bridge_fences_start_without_a_security_config.py
main @ ac3dd6c, test file alone	2 failed, 1 passed - both cells refused with Refusing to start an inbound joint_command surface on an unsecured DDS graph, at docs/ros2-integration.md:401 and docs/rtps-integration.md:165
this head 4c32f4a9, plus the sibling test_ros2_command_surface_flag_domain.py it borrows _init_bridge / fake_dds from	45 passed

ruff check, ruff format --check, mypy clean on the new file. Merge-base diff is the four files the description names (+96/-5). The "described below" the two fence comments point at resolves: ## Securing the inbound command surface at rtps-integration.md:188, and the dds_security_config paragraph at ros2-integration.md:438. The ros2 topic pub line's new comment is accurate too - with ros2_commands=False the bridge subscribes to nothing, so "once commands are on" is the right caveat rather than a stale "drives the arm".

Right scope: the gate is the documented posture (docs/security.md: telemetry-only is ungated), so a docs fix rather than a default change is the correct side to move. The grader's population is derived from the docs tree with dds_security_config fences excluded as the remedy path, so the next RTPS fence is graded on arrival.

Two hardening notes, neither blocking and neither present in today's fences, recorded here rather than as threads so they do not gate the merge:

• ast.literal_eval(value) raises ValueError on a non-literal keyword (ros2_commands=flag), which would fail the module at collection rather than report a verdict. A continue on that except, or skipping the fence with a reason, would keep the grader's own failure mode a verdict.
• _init_bridge fixes ros2_domain=7 itself, so a fence that also sets ros2_domain would arrive as a duplicate keyword. Dropping it from kwargs alongside ros2_transport closes that.

Approving. shipitfast pushed the head, so this approval is from a non-pusher and should count once the required check reports.