fix: fail the scan when a requested -conf cannot be written

[v14d4n]

Fixes #6.

writeConfFile did not return an error: it printed both of its failures to stderr and returned early, so runScanCmd returned nil and the process exited 0 even though the requested config was never created.

What changed

writeConfFile now returns an error and runScanCmd propagates it. Both failures are covered: the write itself, and having no durable endpoint to write a config for.

The error is no longer printed where it happens: main already renders every command error through the same errPal.fail before os.Exit(1), so keeping both would print the line twice. That also matches setupScan, validateThreshold and runRegisterCmd, which return their errors without printing them.

The failure is held in a local and returned at the end rather than early, so the report file is still written: the scan itself succeeded, only the exit status should change. All three exits after the config step propagate it.

Out of scope

A failing report write stays non-fatal: it is written unconditionally under a generated name, so making it fatal would change the exit status of runs that never asked for a file. printBest still calls os.Exit(1) from inside itself on the same condition: same class of problem, separate change.

Test

TestWriteConfFile covers a successful write, an unwritable path, and a run with nothing but torn-down endpoints, asserting the error and that no config file is left behind. The unwritable path is a missing parent directory rather than a read-only one, which root walks straight through. With both returns changed back to nil, the test fails on both assertions.

[vernette]

Thank you!