[adsharma]

Exposes the engine's distributed partition-routing hooks (LadybugDB/ladybug#829) to Rust.

What

• include/lbug_partition_routing.h + src/lbug_partition_routing.cpp: C-ABI shim over common::PartitionRoutingHooks. Point writes materialize into a per-parent row store (bulk writes fan out row-at-a-time); one scan TableFunction per parent serves the store back, so install + insert + read is a complete remote loop with no further machinery. All claimed partitions of a parent share one scan function, which the engine requires to collapse the parent scan (divergent scans read as a local/remote mix and are rejected). lookupRow stays unset (engine default: MERGE over claimed partitions errors).
• src/partition_routing.rs: safe API — RoutingGuard::install (process-global, before opening any Database), placement/lifecycle/write callbacks with decoded Value rows, register_parent_schema for scan serving. Callbacks must be Send + Sync, must not panic (aborts rather than corrupting engine state); uninstall requires no live Databases.
• build.rs: the shim needs full engine headers (common/partition_routing_hook.h), which prebuilt archives do not ship. Reuses a sibling ladybug checkout when present (mirrors LBUG_SOURCE_DIR's ../ladybug default; CI checks it out there) plus generated headers from its build tree, and compiles the module out otherwise.

Tests

New mock-wrapper round-trip test (mirrors the engine's partition_routing_test.cpp): claims every partition of a HASH table remote, covers point + COPY writes, parent-union reads through the bundled scan, lifecycle create/drop counts. Full suite green (159 + 3), fmt clean, no new clippy lints.

Known engine gap (not this PR)

Claiming a LIST partition is broken engine-side as of 0.20: dynamic LIST creation throws raw unordered_map::at instead of routing remotely (the HASH path returns a null table and branches to insertRow; see getOrCreatePartitionLocked). The test therefore exercises HASH; LIST works unclaimed (local) as before.