No cross-database surface: attach/detach unwrapped, and ManagedDatabase discards attachments #90

Re-scoped 1 Sep 2026 after measuring it. This was filed as "attach/detach are unwrapped in
HDLC". That framing was wrong: the platform refuses the attach for managed databases, so
wrapping alone would not have delivered what the downstream workload wanted. What is left is
two smaller, real asks. Original framing kept below the line.

What was measured

Against the live workspace, 31 Aug – 1 Sep:

Attempt	Result
attach managed database A into managed database B	refused — Connection '<id>' is scoped to another database and cannot be attached here
load a result_id from A's query into a table in A	OK, 1 row landed
load the same result_id into B	refused — Result '<id>' not found
attach a Postgres connection into a managed database	accepted
SELECT * FROM catalog.public.drivers through that alias	859 rows, from inside the managed database's scope

ResultsApi.get_result also takes a required x_database_id, which is the same boundary
expressed in a signature.

So: managed databases cannot see each other; registered data sources attach as designed.
The read side of a multi-catalog database already works end to end — query_catalogs()
discovers the alias and sql_tool_description already tells the model to read table_catalog
when there is more than one.

What HDLC should actually do

1. Wrap attach_database_catalog / detach_database_catalog on the framework client and
   expose them, gated like other provisioning tools (see Provisioning boundary: agent-driven database, table, and index lifecycle #61). Today they are raw-SDK only, so
   any consumer wanting a multi-catalog database drops out of the library to build one.
2. Stop discarding attachment state. managed_database_from_detail keeps only id, name
   and default_connection_id. DatabaseDetailResponse also carries default_catalog,
   default_schema and attachments — all three dropped, so a caller cannot ask what is
   attached to a database without going around the library.

Both are ordinary wrapping work. Neither depends on a platform change.

What is not being asked for here

"Let a managed database be attached as a catalog" is a product question, not an HDLC one. It
may well be worth raising — it is a real gap for the agent-creates-databases story — but it
belongs upstream and nothing downstream is waiting on it. The consumer workload has moved to
hosting its shared catalog as a Postgres connection, which is measured working.

Also note fork_database is on no framework version at all — raw SDK only — if anyone
picks that up while in here.

---

Original framing (filed 31 Aug, before measurement)

hotdata-langchain has no cross-database surface at all. Every tool set is scoped to
exactly one ManagedDatabase, resolved once at build time, and execute_sql sends a single
X-Database-Id. The machinery exists on the raw SDK, unwrapped, and every managed database
exposes its catalog handle as ManagedDatabase.default_connection_id — so attaching one
managed database into another looked reachable. Measuring it showed it is not.