refactor: prefer config.toml over inlyne.toml

[mmclinton]

Closes #354

New installs get config.toml. An existing inlyne.toml keeps working indefinitely. It's read and written in place, so there's nothing to rename. When both are present config.toml wins and the ignored one gets named in a warning.

Resolution is shared between startup and config open rather than duplicated, since config open writes back to the path it resolves. Had only the load path learned the new name, config open would have edited one file while startup read the other.

Unit tests cover the four resolution cases (neither file present, legacy only, current only, both) and that a directory named config.toml doesn't shadow a real inlyne.toml. Also checked by hand on Linux and macOS that either name is picked up on its own, and that config.toml wins when both are there:

2026-08-02T20:38:59.210662Z  WARN inlyne::opts::config: Ignoring '/Users/mmc/Library/Application Support/inlyne/inlyne.toml' in favor of '/Users/mmc/Library/Application Support/inlyne/config.toml'

I ran into #471 while working on this. It's a pre-existing bug in the same config open arm and independent of the rename, so it's not included here.

[mmclinton]

Heads up: I've opened #473 (fixes #471, inlyne config open failing on a fresh install). It touches the same two spots this PR does, in src/opts/config.rs and the config open arm of main.rs, so GitHub will flag whichever of the two lands second.

They're independent. No ordering requirement, merge them in whatever order suits you. I'll rebase the second one; what that rebase involves is spelled out in #473's description.