feat(config): migrate config format from JSON to TOML with automatic upgrade path

[CaptainMirage]

What this does

Migrates the user-facing configuration format from JSON to TOML across the
entire codebase. Existing config.json files are automatically translated to
config.toml on the next startup — no manual action required. The JSON parse
path is kept for the migration step and for the Android JNI layer (which
receives config as a string from the Kotlin app).

Changes

Core config loading (src/config.rs)

• Added toml = "0.8" to [dependencies]
• Added Serialize derive to ScriptId (needed for migration write path)
• Defined intermediate TOML structs: TomlRelay, TomlNetwork, TomlScan,
  TomlLogging, TomlConfig — each section maps to a grouped TOML table.
  Default impls on each section struct call the existing named default
  functions so omitting a section in the file gives the same defaults as before
• From<TomlConfig> for Config flattens the grouped representation back into
  the existing flat Config struct. All call sites are unaffected
• From<&Config> for TomlConfig builds the grouped form for migration writes
  and the UI save path
• Config::load_toml(path) — reads and parses a .toml file, converts to
  flat Config, runs validate()
• Config::load updated with a format-dispatch decision tree: .toml
  extension routes to load_toml, .json routes to load_json_and_migrate,
  unknown extension tries TOML first then JSON
• Config::load_json_and_migrate — parses JSON, writes a .toml equivalent
  alongside the JSON file, returns the message to emit as a warn after the
  subscriber is initialised (see logging note below)
• ParseToml(#[from] toml::de::Error) added to ConfigError
• validate() port conflict message updated to reference config.toml

Logging chicken-and-egg fix (src/main.rs, src/config.rs)

The migration warning fires inside Config::load, but the tracing subscriber
is initialised after Config::load returns because log_level lives in the
config. Calling init_logging("warn") before load and a second
init_logging(&config.log_level) after was silently locking all users to
"warn" — tracing's try_init only lets one subscriber register.

Fix: load_json_and_migrate collects the warning message with format!() and
returns it as Option<String> alongside the Config. Config::load return
type changed to Result<(Self, Option<String>), ConfigError>. main.rs
destructures the result, calls init_logging(&config.log_level), then emits
the warning if present. One subscriber, correct user-configured log level,
warning visible.

src/data_dir.rs

• config_path() now returns data_dir/config.toml
• Added json_config_path() returning data_dir/config.json for the
  migration detection path
• resolve_config_path() updated: checks data_dir/config.toml first, then
  data_dir/config.json, then ./config.toml, then ./config.json. Falls
  back to data_dir/config.toml for new users so error messages and Save
  operations point to the right place

src/bin/ui.rs

• save_config changed from serde_json::to_string_pretty(&ConfigWire::from(cfg))
  to toml::to_string_pretty(&TomlConfig::from(cfg)). Saves are now TOML
• Loading block simplified to a single resolve_config_path(None) call,
  removing duplicate two-path check logic that resolve_config_path now owns
• Config::load call site updated to destructure the new
  (Config, Option<String>) return type
• Three UI strings updated from config.json to config.toml (listen_host
  hint, CA-remove log line, CA-remove hover text)

src/android_jni.rs

• TomlConfig added to imports
• startProxy now tries JSON parsing first (backward compat with existing
  Kotlin app), falls back to TOML if JSON fails
• Doc comment updated to be format-agnostic

Example configs

All five JSON example files deleted and replaced with .toml equivalents
using the new grouped schema:

• config.example.toml
• config.direct.example.toml
• config.full.example.toml
• config.exit-node.example.toml
• config.fronting-groups.example.toml

Documentation

All user-facing references to config.json updated to config.toml across
SF_README.md (English and Farsi), docs/guide.md, docs/guide.fa.md,
docs/fronting-groups.md, assets/exit_node/README.md (English and Farsi),
assets/cloudflare/README.md (English and Farsi), assets/launchers/run.bat,
assets/openwrt/mhrv-rs.init, and the Apps Script files. JSON config snippets
in docs replaced with TOML equivalents using correct section syntax.

Migration path for existing users

No action required. On the first run after update:

1. resolve_config_path finds config.json in the data dir or cwd
2. Config::load sees the .json extension and calls load_json_and_migrate
3. JSON is parsed, a config.toml is written alongside it, a warning is
   logged: "Found legacy config.json. Translated to config.toml automatically.
   config.json has been left in place but will no longer be read. You can
   delete it."
4. On all subsequent runs, config.toml is found first and loaded directly

Write failure during migration is non-fatal — the proxy continues running
from the in-memory config.

Tests

• 8 new tests in config::toml_tests:
  • Minimal [relay]-only config parses and validates
  • Omitting [network] applies all defaults correctly
  • [exit_node] table round-trips all fields
  • [[fronting_groups]] array-of-tables parses multiple entries
  • [network.hosts] subtable populates the hosts HashMap
  • script_id as a TOML array round-trips through script_ids_resolved()
  • Config::load dispatches correctly on .toml extension
  • JSON migration writes config.toml alongside and the result round-trips
• Fixed orphaned temp files in rt_tests::round_trip_all_current_fields and
  rt_tests::round_trip_minimal_fields_only — both call Config::load on
  .json temp files which now trigger migration; the written .toml is now
  cleaned up alongside the .json
• Full test suite: 248 tests, 0 failures

---

Why TOML instead of JSON

Here's the Why TOML section rewritten as a short paragraph instead of bullet points:

---

Why TOML instead of JSON

JSON was never designed for config files — it has no comment syntax, requires quoting every key, and a flat structure that stops making sense once you have 30+ fields across multiple logical groups. TOML was built specifically for this. Named sections ([relay], [network], [exit_node]) make it obvious where each setting belongs, # comments survive round-trips so example files can actually explain themselves, and there's no trailing-comma rule to trip over when editing by hand. Parse speed is a non-argument — it's read once at startup, the difference is microseconds. It's also the de facto standard in the Rust ecosystem; Cargo.toml being the most obvious example, so anyone already working in this codebase already knows the format.