fix(config): redact credentials in config get and refuse them in .cu.yml

[timimsms]

Summary

Completes the credential surface started in #46, which left two gaps I flagged in review there.

config get <key> still printed the token in full. The case for leaving it alone was that naming the key is a deliberate act — but that does not match what redaction actually defends against, which is incidental disclosure: pasted terminal output, a screen-share, a script whose stdout lands in a CI log. get is the spelling most likely to be captured by one. And it was never a route to a secret cu uses, since authentication reads the keyring, so redacting costs nothing real.

$ cu config get api_token            # stdout — what a pipe or a log captures
<redacted — cu authenticates via the system keyring, not this file>

$ cu config get api_token 2>&1 >/dev/null    # stderr — what a person sees
"api_token" is not printed. cu authenticates via the system keyring; this value is an unused plaintext leftover.
To read or remove it, edit /home/you/.config/cu/config.yaml directly.

Splitting the streams is the point: piped output stays clean, while an interactive user is told exactly where the value lives and how to remove it. GlobalConfigPath is exported so that path is the one Save really writes rather than a guess.

SaveProjectConfig wrote its settings map verbatim. Init already refuses to read a credential back out of .cu.yml, so writing one there would strand a plaintext secret on disk that cu never uses — the exact state the refusal exists to prevent, reached from the other direction. The only caller passes default_list, so this was latent rather than live.

Both directions now share one stripCredentials helper. It copies rather than deleting in place, so a caller that reuses its settings map does not silently lose keys — covered by its own test.

Behavior deliberately unchanged

A pre-existing plaintext token is still preserved, not scrubbed, exactly as #46 decided. Redaction hides it from casual output; it does not delete the user's data, and get now names the file so removing it by hand is obvious.

Tests

Five tests across both packages: the get and list redaction paths, the .cu.yml write guard, the caller-map-not-mutated property, and that GlobalConfigPath names the file Save actually writes. I verified the two behavioral ones fail without the change rather than passing vacuously — reverting the get redaction and the SaveProjectConfig guard each produces a failure naming the leaked value.

Note on provenance

These four files were briefly swept into #48 by a concurrent commit in the same working tree; that PR's message describes only the search/export work, so the credential change was riding along undisclosed. This PR carries them on a clean main base. #48 should have them removed so each gets reviewed on its own terms.

Checklist

• go build, go vet, gofmt, and the full test suite pass on a clean origin/main base
• Behavior verified end-to-end against a built binary with a seeded legacy token
• Commit messages use conventional prefixes
• No command help text changed, so no doc regeneration needed