Resolve the CLI's language for every command, not by accident

[YCistak]

pylon update answered in English on a machine set to Turkish.

The language was resolved inside loadConfig(), and most commands reach that only on their way somewhere else: they call socketPath() to find the daemon, and socketPath() loads the config. update talks to no daemon and reads no config, so it fell through both and ran on the default.

It is resolved once in main() now, before dispatch — where a process-wide setting belongs, rather than as a side effect of path lookup. An unreadable config no longer silences the preference either: the preference file and the environment never depended on it.

Found while verifying the v0.1.0 release, after the update path had already shipped.

Verification

Same directory, same conditions, from outside the checkout:

$ /path/to/released/v0.1.0/pylon update --check
You're already up to date (v0.1.0).

$ ./pylon update --check          # this build
Yeni sürüm var: v0.1.0 (şu an v0.1.0-dirty)

Two tests pin the resolution: the preference wins, and a config that will not parse does not suppress it.

⚠️ What the tests do not cover: they call setLanguage() directly, so deleting the call from main() would not fail them. The wiring is covered only by the run above. Testing it properly means executing the built binary, which this package's tests do not do for anything else.

Not a bug, but worth knowing

Running pylon from a checkout looks for the preference file beside that checkout's pylon.yaml, not in ~/.config/pylon, because prefDir() is filepath.Dir(configPath()). So inside the repo this build still prints English — the preference there is genuinely unset. That is the documented behaviour (a checkout uses its own config, and the preference overrides the config it sits next to), and this PR does not change it.

🤖 Generated with Claude Code