[codex] Honor config env fallbacks

[AmAzing129]

Background

The docs say values can be supplied through the [env] table in config.toml, but the implementation only resolved real process environment variables through os.Getenv. That made doctor, GitHub/OpenAI token detection, and config-backed model overrides disagree with the documented behavior.

The underlying design issue was that one config struct was being used both as the persisted file shape and as the runtime effective config. If runtime fallbacks are applied directly during normal Load, a later Load -> edit -> Save path can materialize process env or [env] fallback values into top-level persisted fields.

Changes

• Add Config.Env support for the TOML [env] table.
• Keep Load / Save on the persisted config layer: defaults and path normalization only, no runtime env overlay.
• Add LoadRuntime / ApplyRuntimeEnv for commands that need the effective runtime config.
• Resolve env-derived values from process env first, then config.toml [env] as a fallback.
• Apply runtime fallback to GitHub/OpenAI tokens, DB path override, and summary/embed model overrides.
• Update runtime callers such as sync, doctor, status, and local runtime opening to use LoadRuntime.
• Pass resolved GitHub tokens from [env] into real gh subprocesses for both direct passthrough and cached fallback capture paths.
• Update the configuration docs to describe [env] as a fallback rather than process-wide env injection.

Root cause

config.Load decoded TOML into a default-seeded config, but token resolution only checked os.Getenv, and model override fallback only ran when fields were empty. Fixing that directly exposed the larger layering problem: applying runtime fallback values inside Load mutates the same struct later used by Save, so unrelated config edits could persist fallback values.

The gh shim also needed explicit subprocess env handling. Local sync could use [env].GITHUB_TOKEN, but fallback calls to the real gh binary inherited only the process environment, so gitcrawl gh ... could run unauthenticated when the token existed only in config.toml.

Validation

• GOWORK=off go test ./internal/config
• GOWORK=off go test ./internal/cli -run 'TestGHShim(PassThroughUsesConfigEnvToken|CachedFallbackUsesConfigEnvToken|FallsBackForUnsupportedRead)'
• GOWORK=off go test ./...
• Smoke-tested go run ./cmd/gitcrawl --config <tmp-config-with-[env]> --json doctor and confirmed token sources plus model overrides report from config.toml [env].
• Smoke-tested gitcrawl configure with conflicting process-env and [env] model fallbacks and confirmed those fallback values are not written into [openai].

[AmAzing129]

If the env isn't what's expected, updating the documentation would also work.