…E_DB_TYPE

Two related bugs that together cause silent backend mis-routing, particularly
on Windows where FalkorDB Lite is unavailable:

**Bug 1 — server.py: resolver verdict unconditionally overwrites process env**

`MCPServer.__init__` sets `os.environ["CGC_RUNTIME_DB_TYPE"] = ctx.database`
whenever `resolve_context()` returns a non-empty `database` field. This
overwrites any value the user (or launcher wrapper) already placed in the
process env — e.g. via `CGC_RUNTIME_DB_TYPE=falkordb-remote` in a project's
`.mcp.json` env block — with whatever the resolver defaulted to.

Fix: only write when the variable is not already set:
  `if ctx.database and not os.environ.get("CGC_RUNTIME_DB_TYPE"):`

**Bug 2 — config_manager.py: per-repo branch ignores process env for default**

When `resolve_context()` takes the per-repo branch (local `.codegraphcontext/`
folder present), it initialises `local_db` from
`load_config().get("DEFAULT_DATABASE", "falkordb")`. `load_config()` reads
`.env` files from disk; it does not consult the current process environment.
So `CGC_RUNTIME_DB_TYPE=falkordb-remote` in the MCP launcher env is invisible
here and the resolver defaults to bare `"falkordb"`.

Fix: check process env before file-based config:
  `local_db = (os.environ.get("CGC_RUNTIME_DB_TYPE")
               or os.environ.get("DEFAULT_DATABASE")
               or load_config().get("DEFAULT_DATABASE", "falkordb"))`

An explicit `database:` key in the repo-local `config.yaml` still takes
precedence over all of the above (`local_db = local_raw.get("database", local_db)`).

**Combined failure mode (Windows + per-repo folder)**

With both bugs active: a repo with a `.codegraphcontext/` folder but no
pinning `config.yaml` causes the per-repo branch to fire, default to
`database="falkordb"` (Lite), write that back to `CGC_RUNTIME_DB_TYPE`, and
then `get_database_manager()` picks up "falkordb". FalkorDB Lite is
unavailable on Windows (`core/__init__.py:93-98` falls back to KuzuDB). The
KuzuDB single-writer lock then crashes `cgc mcp start` with a -32000 error,
leaving a zombie process and silently discarding the `falkordb-remote`
settings the user configured.

**Workaround** (still needed until this is released): add a
`.codegraphcontext/config.yaml` pinning `database: falkordb-remote` to any
repo that uses the remote backend and carries a local `.codegraphcontext/`
folder.