Hardcoded 'hq' database name prevents multiple cities sharing a remote Dolt server

[elmpp]

Problem

defaultScopeDoltDatabase() in beads_provider_lifecycle.go:276 hardcodes the city-level database name to hq:

func defaultScopeDoltDatabase(cityPath, dir, prefix string) string {
    if samePath(cityPath, dir) {
        return "hq"
    }
    return prefix
}

This means every city that connects to the same remote Dolt server will use the same hq database, causing collisions. Rig databases are correctly scoped by prefix, but the city's own beads store is not.

Context

The hq hardcoding was introduced in #147 / #184 to give the city HQ store a stable, conventional name instead of deriving it from the city name (which produced confusing prefixes like ga for gascity). That made sense for single-city-per-server deployments.

With #790 (merged 2026-04-17) now correctly propagating [dolt] host/port from city.toml to .beads/config.yaml for remote Dolt servers, multi-city remote Dolt becomes a realistic topology — but the hardcoded hq database name blocks it.

Reproduction

1. Deploy a single remote Dolt server (e.g. via Helm chart to k3s)
2. Create two cities pointing at the same server:

# city-a.toml
[workspace]
name = "city-a"

[dolt]
host = "dolt.k3s.lan"
port = 3307

# city-b.toml
[workspace]
name = "city-b"

[dolt]
host = "dolt.k3s.lan"
port = 3307

3. gc init city-a --file city-a.toml → creates database hq on remote Dolt
4. gc init city-b --file city-b.toml → collides on the same hq database

Both cities read/write each other's beads.

Additional observation

Separately, when gc init hits a transient network error during CREATE DATABASE IF NOT EXISTS hq, the error recovery path in gc-beads-bd.sh detects the existing hq database (from a previous city) and aborts with "This workspace is already initialized" — even though it's a different city. The IF NOT EXISTS clause never gets a chance to work because the SQL call itself failed; the "already initialized" comes from bd init seeing on-disk .beads/ state plus the existing remote database.

Suggested direction

Could the database name be scoped per-city? For example:

• Use EffectiveHQPrefix as the database name (instead of just the bead ID prefix)
• Or derive from city name: city-a → database city_a_hq
• Or allow [dolt] database = "my-city-hq" in city.toml

The [workspace] prefix field from #184 already gives each city a unique prefix — it seems like a natural candidate for also scoping the database name.

Question

Is multi-city on a single remote Dolt server an intended topology? If so, the hq hardcoding needs to become city-scoped. If not, it would be helpful to document that each city requires its own Dolt server instance.

[sjarmak]

Filed as part of architectural review #1248. Proposed fix: Shift B (#1250) step 6 — replace hardcoded defaultScopeDoltDatabase("hq") at cmd/gc/beads_provider_lifecycle.go:276 with a [workspace] prefix-derived database name. Includes one-shot doctor migration that detects an existing hq database on a remote dolt server and renames it idempotently.