fix(config): report config values that cannot be applied to their flag

[JonJagger]

Closes the silent-exit half of #1086.

A config file value that fails to apply to its flag was reported with logger.Error inside bindFlags. That is
Fatalf, and the logger's error stream is not wired up there, so the process exited 1 with no output at all.

bindFlags now returns the failure and initialize propagates it. The message names the flag, the config file, and
the format pflag expected.

The YAML list/map handling in #1086 is deliberately not addressed here.

Stacked on #1087's branch; rebase onto main once that merges.

[claude]

Claude finished @JonJagger's task in 1m 56s —— View job

---

Claude PR Review

• Gather context (read changed files, diff vs origin/main)
• Static analysis (go build, go vet)
• Review code quality, edge cases, bugs, tests
• Post review

---

Verdict: Looks good to merge. The core fix is correct and the code is unusually well-documented for why it does what it does.

Static analysis

• go build ./... — ✅ clean
• go vet ./cmd/kosli/ — ✅ clean
• No dependency changes (errors/os are already imported).

The fix is sound

bindFlags now returns its error via errors.Join instead of the old dead logger.Error-inside-a-closure path, and initialize propagates it (root.go:544-546). Previously the failure was routed through logger.Error (a Fatalf) on an error stream that isn't wired up yet, so the process exited 1 with no output — the silent exit from #1086. That's genuinely fixed, and the message now names the flag, the source, and the format pflag expected (root.go:641-643).

Previous review comments — all addressed ✅

Tracking the earlier bot-review threads on this PR, each has been resolved in later commits:

• Last-error-wins → now accumulates with errors.Join, and TestAllConfigValuesThatCannotBeAppliedAreReported pins that both bad keys are reported.
• Source misattribution → configValueSource (root.go:578-584) mirrors viper's env-vs-file precedence, with TestUnappliableValueFromEnvNamesTheEnvVar covering the env path.
• Stale/contradictory doc comment + orphaned fragment → reworded to describe what the test pins (root_test.go:137-141).
• Config-file source not asserted → root_test.go:148-149 now asserts the file name.
• Duplicated Require().Error → dropped.

Nice touches

• The configValueSource doc comment (root.go:565-577) explicitly calls out the invariant that keeps its manual precedence mirror honest (AllowEmptyEnv(false), caller reached only when viper supplied a value) and warns what to change if AutomaticEnv config drifts. That's exactly the kind of comment that prevents a future silent regression.
• The empty-env-var-vs-encrypted-token reasoning (root.go:596-604) is a subtle correctness point (an empty KOSLI_API_TOKEN must not skip decryption of a config-file token) and it's well guarded.

Minor observations (non-blocking)

1. Test failure trigger is implicit. invalid-flag-value.yaml triggers the error because link: is a YAML map, so fmt.Sprintf("%v", val) renders map[docs:...] which --link can't parse. That's fine and intentional (the YAML map handling is explicitly deferred per the PR description), but the test's red state quietly depends on that rendering. A one-line comment in the fixture, or switching link to a plainly-unparseable scalar, would make the intent self-evident. two-invalid-flag-values.yaml is clearer since max-api-retries: not-a-number is an obvious int-parse failure.
2. configValueSource scope. It distinguishes config-file vs env only — if a value ever originated from v.Set/an alias it would be attributed to the config file. Not reachable through today's binding, and the doc comment scopes this correctly, so just noting it.

Overall a tight, well-reasoned fix with good test coverage of both source-attribution paths. 👍