Stop hand-building connection-scoped URLs from default_connection_id

[zfarrell]

The CLI reads default_connection_id off the database response and hand-builds connection-scoped URLs with format!, bypassing the generated SDK. When runtimedb renames the surface to catalogs (hotdata-dev/runtimedb#1104), these break in a way the SDK regen won't catch, because the paths aren't coming from the SDK.

Hand-built paths

• src/commands/databases.rs:647 — managed_table_load_path() -> /connections/{connection_id}/schemas/{schema}/tables/{table}/loads
• src/commands/databases.rs:651 — managed_table_delete_path() -> /connections/{connection_id}/schemas/{schema}/tables/{table}
• src/commands/indexes.rs — the index list/create/delete paths, /v1/connections/{id}/tables/{schema}/{table}/indexes[/{index_name}]

Where the id comes from

default_connection_id is read at src/commands/connections.rs:38,52, src/commands/tables.rs:173, src/commands/indexes.rs:225, src/main.rs:547, and src/commands/databases.rs:1555,1673,1694,1800,1863, plus the local struct definitions at databases.rs:290,331.

Ask

Two parts, and the first is worth doing regardless of the rename:

1. Route these calls through the generated SDK instead of format!, so a spec change surfaces as a compile error rather than a 404 at runtime.
2. Where a hand-built path is genuinely unavoidable, centralise it in one place so the rename is a single edit.

Once runtimedb dual-emits default_catalog_id, switch the field read and drop the local default_connection_id mirrors. The old path aliases will keep working during the deprecation window, so this doesn't have to land in lockstep — but it does have to land before the aliases are removed.

The mock-based tests in indexes.rs and databases.rs assert the literal /v1/connections/... strings, so they'll need updating with whatever shape lands.