test: add coverage for the config subcommand (show, set, unset)

[chiliec]

What changed and why

src/cli/config-command.ts (runConfigCommand) had no test coverage. This adds tests/cli/config-command.test.ts covering all of its branches:

• show with no config prints No configuration set. and the config file path
• show with a ca-cert configured prints the key and its value
• set with a valid PEM path stores it (asserted via readConfig())
• set with an invalid path surfaces the cannot read file validation error and writes nothing
• unset removes a previously stored value
• unset with nothing set reports it is not set

The command writes to console.log, so the tests capture it with jest.spyOn(console, "log"). os.homedir() is stubbed to a mkdtempSync temp dir per test so the real ~/.cve-lite-cli/config.json is never touched (in-process, os.homedir() ignores $HOME, unlike the child-process e2e tests). Style mirrors the existing tests/cli/config.test.ts.

No source changed — test-only.

Validation

npm run lint:tests   # test hygiene: passed
node --experimental-vm-modules ./node_modules/jest/bin/jest.js tests/cli/config-command.test.ts
#   Tests: 6 passed, 6 total

RED→GREEN: gutting runConfigCommand's body turns all 6 tests red; restoring it turns them green, so the tests exercise real behavior rather than passing vacuously.

tsc -p tsconfig.test.json --noEmit reports no errors in this file (pre-existing errors in other unrelated test files are untouched). One unrelated test, tests/cli/scan-fix-verify-exitcode.test.ts, fails on a clean checkout here too (independent of this PR, confirmed by removing this file and rerunning) — happy to look if that's unexpected on CI.

Closes #1090

[sonukapoor]

This is solid. I mutation-tested it rather than just reading it: 17 of 20 mutations to config-command.ts were caught, including every wording change, both writeConfig calls, the keys.length === 0 guard, and the validation call.

Two things I want to call out. It tests the real module and verifies persistence through the actual readConfig(), rather than reimplementing the logic in the test body. We had exactly that problem in another PR last week, so it is good to see it done properly here. And the os.homedir spy genuinely isolates the temp home; I checksummed my real config before and after the run and it was untouched.

Three mutations survived, all the same gap. config-command.ts prints Config file: <path> on four paths and the tests assert it on one, so removing that line from the populated show, set and unset paths leaves the suite green. One line per test closes it:

expect(logged.join("\n")).toContain(getConfigPath());

Not holding the merge for it. If you want a quick follow-up it is a good one, and it is a nice illustration of what mutation testing catches that coverage percentages do not.

Two corrections on the description, neither affecting the code. os.homedir() does honour $HOME, I checked: setting it and calling os.homedir() returns the override. Your spy approach is still the better choice because it also works on Windows where USERPROFILE is what matters. And the scan-fix-verify-exitcode failure you mentioned does not reproduce here, on your branch or rebased on main, so main is not broken. Likely local.

[sonukapoor]

Merged, thank you @chiliec.