Add geographic_msgs (+ uuid_msgs) and regenerate all bindings

[leshy]

Adds ROS geographic_msgs as LCM types and regenerates bindings for every language we support.

What's here

• Vendored geographic_msgs 0.5.6 and uuid_msgs from ros-geographic-info into sources/ros_msgs/ (canonical upstream for the kinetic API docs; uuid_msgs/UniqueID comes along because 8 of the geographic messages reference it for identifiers).
• 17 new LCM defs: the 16 geographic_msgs messages (GeoPoint, GeoPose, GeoPoseStamped, GeoPoseWithCovariance(Stamped), GeoPath, GeoPointStamped, BoundingBox, KeyValue, WayPoint, MapFeature, GeographicMap, GeographicMapChanges, RouteNetwork, RoutePath, RouteSegment) plus uuid_msgs.UniqueID.
• Regenerated Python, C++, C#, Java, Lua, TypeScript and Rust bindings via ./generate.sh.

Three hand-maintained package lists that codegen does not touch also needed the new packages:

File	Why
generated/python_lcm_msgs/fix_imports.py	MSG_PACKAGES is hardcoded — without it the generated Python emits bare import std_msgs and import geographic_msgs, so the package fails to import at all
pyproject.toml	packages / package-dir for the PyPI wheel
tools/ts/msgs/{mod.ts,deno.json}	exports + _registerPackage decode registry

Version bumps: dimos_lcm 0.1.3 → 0.1.4, @dimos/msgs 0.1.4 → 0.1.5 (both publish new packages). Drop them if you'd rather bump at release time.

Two fixes that came out of this

RouteSegment broke the Lua backend. The ROS message has a field literally named end, a Lua keyword, and lcm-gen emitted obj.end = nil — a file luac refuses to parse. Fixed in our lcm fork (dimensionalOS/lcm#2, merged) by quoting reserved-word names as obj["end"]; flake.lock here bumps to 553171c to pick it up. Regenerating changes exactly one file. All 206 generated Lua files now pass luac -p, and RouteSegment round-trips with the end field intact.

generate.sh deleted hand-written files. Both the Rust and TypeScript steps rm -rf'd their whole output directory before regenerating, destroying generated/rust_lcm_msgs/{.gitignore,tests/} and generated/ts_lcm_msgs/{mod.ts,deno.json} on every run — four spurious deletions in anyone's diff. Now each step clears only what its generator actually rewrites. A full run leaves zero unintended deletions.

Verification

Cross-language fingerprint + wire check on GeoPoseStamped — all four runnable targets agree on hash 0x7300003f68de379f and an 84-byte encoding:

Language	Result
Python	all 17 types encode/decode round-trip
C++	compiles against lcm 1.5.2 headers, round-trips, hashes match
TypeScript	deno check clean, round-trips, hashes match
Rust	cargo check + cargo test (7 passed), round-trips, hashes match
Lua	all 206 files pass luac -p; RouteSegment round-trips including end
Java	new packages compile clean against the lcm runtime
C#	generated; not compile-verified, see below

Known issues (pre-existing, not fixed here)

1. C#/Java std_msgs breakage. std_msgs.String shadows the builtin String inside the std_msgs namespace, so any message with a std_msgs.Header fails to compile. Verified against main: identical failures in untouched geometry_msgs (28 C# errors) and std_msgs itself (9 Java errors, 140 C# errors). Nothing new from this PR; worth its own fix.

2. UniqueID() default doesn't encode. Stock lcm-gen Python defaults the fixed byte uuid[16] field to b"" and encodes self.uuid[:16], so a default-constructed UniqueID writes 0 bytes where the decoder expects 16. Populate all 16 bytes before encoding. C++/Rust/TS all handle the fixed array correctly.

🤖 Generated with Claude Code