Layer settings over a file that documents itself

Compiled default, then the file, then the environment -- with the
environment winning, which is the reverse of the usual arrangement and is the
point: LUMBRIDGE_CLAUDE_OAUTH=0 is documented as one switch off, and a switch
a configuration file can silently turn back on is not a switch. Where a
variable has pinned a value the settings pane shows that row disabled and
names the variable rather than accepting an edit that would do nothing.

default.toml carries every key Lumbridge understands, commented out, showing
the compiled default, and a test uncomments them and asserts the key set is
exactly the set the binary knows -- so neither half can drift from the other.
toml reads and toml_edit writes, because serialising the parsed model back
over the file would strip every comment and every key this build does not
recognise, and here the comments are the documentation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SPYebLiN2w4TqnHUYGdECq

crates/lumbridge-settings/src/lib.rs

@@ -27,14 +27,27 @@
 //! file that can redirect where an access token is sent is a credential
 //! exfiltration path with a friendly name.
 
+//!
+//! **The file is edited, never regenerated.** [`file`] rewrites the one key
+//! that changed through `toml_edit`, so a hand-written file keeps its comments,
+//! its ordering, and any key a newer build wrote that this one does not
+//! understand. `assets/default.toml` is the reference file, and it is the
+//! documentation: a test asserts it names every setting in [`SETTINGS`].
+
 #![forbid(unsafe_code)]
 
+pub mod file;
 pub mod paths;
 
 use std::collections::BTreeMap;
 
 use serde::{Deserialize, Serialize};
 
+pub use file::{
+    DEFAULT_TOML, LoadOutcome, ParseFailure, SettingValue, SettingsFile, WriteError, WriteOrigin,
+    load,
+};
+
 /// Who is allowed to write a field.
 #[derive(Clone, Copy, Debug, Eq, PartialEq)]
 pub enum WriteAuthority {