Set the default KB when creating a knowledge base

[williamthorsen]

Builds on: #793 (kb set-default, merged)

Problem

kb create registers a new KB under kbs: in ~/.agents/kb.yaml but never touches the top-level default_kb pointer added in #786. Because the only kb subcommands today are create and check, there is no programmatic way to populate default_kb at all — a user who runs kb create ends up with a registered KB but no default unless they hand-edit the YAML. A fresh user's first kb create should leave them with a working default and zero manual steps.

Context

• registerStore (packages/kb/src/discovery/register-store.ts) writes the kbs entry; Set the default knowledge base from the command line #793's setDefaultKb writes the default_kb pointer. Both validate against the schema and rewrite the whole file.
• default_kb is a strict pointer: loadKbRegistry throws if it names an unregistered KB. Setting it to the just-registered KB is therefore always self-consistent.
• kb create writes only to the user-global ~/.agents/kb.yaml; the auto-set default is machine-wide (user scope), independent of any project-local overlay.
• Set the default knowledge base from the command line #793 introduces kb set-default with a named form and an interactive picker. This ticket reuses that picker for the ambiguous case.

Proposed solution

After kb create successfully registers a KB, ensure a default_kb is configured — choosing automatically only when there is no real choice to make:

• default_kb already set → leave it untouched (never overwrite an existing default).
• default_kb unset and the new KB is the only one in the user-global registry → set default_kb to the new KB.
• default_kb unset and other KBs are already registered → delegate to kb set-default's interactive picker so the user chooses among all registered KBs, rather than having the freshly-created one chosen for them.

Keep the deterministic auto-set in the pure core; keep interactive delegation in the CLI layer, where prompting belongs. The "only KB" determination and the default_kb read/write are evaluated against the user-global registry file being written, not the merged project+user view.

Acceptance criteria

Must have

• When kb create registers a KB and the user-global default_kb is unset with no other KBs registered, default_kb becomes the new KB's name.
• An existing default_kb is never overwritten by kb create.
• When default_kb is unset and other KBs are already registered, kb create lets the user choose the default via kb set-default's picker rather than auto-selecting the new KB.
• If the user cancels the picker in the ambiguous case, kb create still exits successfully with the KB created and registered, and default_kb left unset.
• kb create --no-register never modifies the registry, including default_kb.
• No kb create failure leaves a corrupt or partially-written kb.yaml.
• kb create output states when it has set the default.
• New and changed behavior is covered by tests.
• README ### kb create and kb create --help document the default-setting behavior; no stale claims remain.

Should have

• Default-state and KB-count checks are evaluated against the user-global registry file being written, not the merged project+user view.

[williamthorsen]

Design note from #793 planning — reuse mechanism

#793 exposes its pieces as composable, importable functions rather than a single bundled selectAndSetDefault. The picker is a UI concern (terminal I/O) and the write is a registry concern; this ticket's two write paths use one each, never both as a unit, so bundling them would be the wrong shape.

What #793 makes available:

• setDefaultKb / clearDefaultKb — write or clear the pointer, no prompt.
• the interactive picker (createReadlineSelectKbPrompt and the SelectKbPrompt type).
• runSetDefault — the no-argument interactive handler (list → pick → write → cancel), callable as a function with an injected picker.

How this ticket should consume them:

• Deterministic single-KB auto-set (no default, exactly one KB) → call setDefaultKb, folded into the same atomic registerStore write.
• Ambiguous case (no default, multiple KBs) → invoke kb set-default's no-argument interactive handler (runSetDefault) and forward its result. Calling the handler here is correct — the caller genuinely is running interactively.

There is no selectAndSetDefault to depend on; compose the pieces above per branch.