Initial developer experience: `tapes config list` is misleading before setup

[bdougie]

Summary

New contributors hit confusing signals on first run, even without running tapes init. The tool appears to be in a broken/uninitialized state when it's actually working fine with defaults.

What's confusing

1. sqlite_path = <not set> doesn't indicate whether storage is disabled or falling back to a default. Sessions are in fact being written to ~/.tapes/tapes.sqlite, but nothing in tapes config list says so.
2. ~/.tapes/config.toml exists without running tapes init. Something on first run (likely tapes serve or the proxy) auto-creates a skeleton config, which contradicts the mental model of "I haven't initialized anything yet."
3. The config file path is printed once at the top of tapes config list, easy to miss while scanning key/value rows for the setting you care about.

Repro

Fresh machine, no tapes init:

tapes serve api &         # or any first invocation that boots services
tapes config list

Observe: config file path exists, storage.sqlite_path <not set>, no indication where data is actually going.

Suggestions

• Show effective values next to overrides, e.g. storage.sqlite_path <not set> (default: ~/.tapes/tapes.sqlite).
• Add a tapes config doctor (or extend config list --verbose) that prints the resolved storage path, DB size, and row counts so users can confirm "yes, data is landing here."
• Either don't auto-create config.toml until the user runs init, or print a one-line notice the first time it's created: created ~/.tapes/config.toml with defaults.

Context

Caught by a new contributor during onboarding. Early-stage oversight — low severity, but it's the first impression for everyone joining.

[linear]

PCC-332