fix(config): treat empty KOSLI_* env vars as unset, not as set

[JonJagger]

An environment variable set to the empty string reports as present via
os.LookupEnv, and two hand-rolled reads took that as evidence the user had
supplied a value.

KOSLI_CONFIG_FILE="" replaced the default config path with "", so no config
file was loaded at all and org, api-token and every other configured default
vanished silently.

KOSLI_API_TOKEN="" was read as "the token came from the environment, so it is
plaintext", which skipped decryption of the config-file token. Anyone who
stored their token with kosli config --api-token holds ciphertext, so the
ciphertext was sent as the API token and authentication failed with nothing
pointing at the skipped decryption step.

Both now require a non-empty value, matching how viper already treats every
other bound KOSLI_* variable. Making an empty variable an error is left to the
wider AllowEmptyEnv work, so they all change together rather than two of them
diverging again.

Checklist

• Docs are autogenerated from CLI help — make sure the help text reflects your changes
• Helm chart (charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR
• Terraform provider and related changes (terraform-provider-kosli, terraform-aws-evidence-reporter, terraform-aws-kosli-reporter) updated, if needed

[claude]

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

---

Code Review: treat empty KOSLI_* env vars as unset

Verdict: LGTM. Correct, well-scoped fix with clear tests and excellent explanatory comments.

What was checked

• Read both changed files (root.go, root_test.go)
• go build ./... — passes
• go vet ./cmd/... — passes
• Swept for other direct KOSLI_* reads with the same bug
• Code review

Correctness

Both hand-rolled reads bypassed viper, so they never benefited from viper's default AllowEmptyEnv=false (which treats an empty env var as unset). The fix restores that semantics for the two outliers:

• root.go:497 — exists && path != "" stops an empty KOSLI_CONFIG_FILE from blanking the config path and silently dropping every configured default. ✅
• root.go:570-571 — apiTokenPresentInEnv && apiTokenFromEnv != "" stops an empty KOSLI_API_TOKEN from being read as "token came from env, so it's plaintext," which had skipped decryption and sent ciphertext. ✅

I confirmed the alignment claim: with KOSLI_API_TOKEN="", viper's v.IsSet("api-token") returns false for the empty env and true from the config file, so !apiTokenSetInEnv is now true and the decrypt branch is correctly entered. Consistent with every other bound flag.

No other instances of the bug

I swept for direct env reads of KOSLI_* vars in production code. The only other one is main.go:154 (KOSLI_DEBUG), which is parsed via strconv.ParseBool and safely ignores an empty value (err path), so it's unaffected. Nothing else regresses.

Testing

TestEmptyApiTokenEnvVarStillDecryptsConfigToken and TestEmptyConfigFileEnvVarFallsBackToDefault are targeted regression pins with t.Setenv for isolation. The comment explaining why the "as plain text" warning is a stable marker for "decryption branch was entered" is a genuinely good bit of documentation — it makes the test robust against whether an encryption key exists in the credentials store.

Minor (optional, non-blocking)

The idiom exists && val != "" now appears in two places. If more direct KOSLI_* reads are added later, a tiny helper (e.g. lookupNonEmptyEnv(name) (string, bool)) would keep them from diverging again — matching the spirit of the PR description ("so they all change together"). Not worth doing for just two call sites.

Docs / help text

No user-facing flag help or output changed, so the autogenerated docs checklist item is a no-op here. Correct to leave it.

Nice work — the commit message and PR description read as a model of explaining root cause and blast radius.