id-first: first-run auto-create + read-back in one process needs a pinned database_id #61

Summary

Since 0.11.0 (#59), managed databases are addressed strictly by id. A process that auto-creates a database (no database_id configured) and then reads it back in the same process — e.g. pipeline.run() then pipeline.dataset()... — fails with:

DatabaseTerminalException: 'no managed database resolved for this run (set database_id)'

Fails loud and safe (never touches the wrong DB), and pinning database_id avoids it entirely. This is the id-first tradeoff surfacing on the read side, not a correctness bug — but it regresses a common convenience (on main/pre-0.11.0 the read resolved the shared name).

Root cause

The write path creates the DB and caches its record on its HotdataClientConfiguration instance (_hotdata_db). pipeline.dataset() builds a read client with a different config instance — no pinned database_id, and it can't see the write's run cache. So the read has no id to resolve, and there's no by-name fallback anymore (removed on purpose — names aren't unique).

Scope of impact

• ✅ Production ingestion (write, pin the id after first run) — works, unaffected.
• ✅ Query from a separate process with the id — works.
• ❌ Load then read-back in the same script (notebooks, exploration, verify scripts) — errors without a pinned id.
• The demos were worked around by provisioning + pinning the id up front (roundtrip/merge/ibis); demo.py (write-only) is unaffected.

Options

• A — accept (strict id-first): document that reads require a pinned database_id; keep the workaround demos do. Matches the "require ids" direction exactly; keeps the regression.
• B — in-process created-db memo: a process-level map of DBs created this process, keyed by (workspace_id, database_name), consulted between the config cache and create — so same-process read-after-write resolves by id without a pinned id and without any API name scan. Wire stays id-only; collision-free (only ever returns our own creations). Trade-off: a local name-keyed memo, which lightly bends "strictly by id" — wants @eddietejeda's input since it's his direction.

Test gap to close regardless

The e2e fixtures (_dest in tests/test_e2e_inmemory.py) pin database_id on every test, so the auto-create → read-back (no id) path has zero coverage — which is why this wasn't caught pre-release. Add that test with whichever option lands.

Docs dependency

The README "Read your data back" section was corrected to the as-released (pin-required) wording in #60. If option B lands, that section relaxes again ("same pipeline object reads, no id needed").

Context: 0.11.0, PR #59.