List the documented /config and /health keys in the served order - #372

Problem

serde_json is built without preserve_order, so serde_json::Map is a BTreeMap and every object /config and /health return goes out with its keys ascending, at every nesting level. The documented samples were written in the order the json! literals declare the fields — network, workers, timeouts.

The keys themselves were right, all thirty-six of them on /config, and so was every value. Only the position was wrong, which is enough to stop a sample being usable as the baseline for a diff against a live response, and to send a reader looking for a setting several lines from where it turns out to be.

The scope is wider than it first looks. Seven blocks across three pages:

/health is built by the same json! in build_health_json and sorts the same way. The nested plugins object in configuration.md was wrong twice over: otel came before apm, and apm's own settings were not ascending either.

Why not preserve_order

Enabling the feature and leaving the samples alone was the obvious alternative. It was rejected because it breaks the very scenario this fixes.

PluginManager::config_json() serializes config_values: HashMap<String, HashMap<String, Value>> through serde_json::to_value. Today that lands in a BTreeMap and comes out sorted, so the plugins subtree is stable across restarts. Under preserve_order it would land in an IndexMap and inherit the HashMap iteration order, which std randomizes per process via RandomState — plugins would reshuffle on every restart, making a diff against a live response worse rather than better. Avoiding that would mean converting plugin/manager.rs, plugin/context.rs and five plugins' config to BTreeMap, plus a Cargo.lock change pulling THIRD_PARTY_LICENSES.html and cargo deny behind it — and it would make the textual order of every json! literal in the project an observable contract.

Alphabetical is also not the worse order to read: finding a key by name among thirty-six is easiest alphabetically, and the grouped reference already exists as the settings table in docs/operations/configuration.md. A JSON sample's job is to show what actually arrives.

What is deliberately not touched

docs/features/profiling.md's index.json sample is correct and was left alone. RunMeta is a #[derive(Serialize)] struct written with serde_json::to_vec, and serde's text path streams fields in declaration order without ever building a Map. Worth stating precisely, because the premise is narrower than it sounds: this holds for to_string/to_vec/to_writer only — serde_json::to_value(&struct) does go through Map and sorts.

docs/getting-started/installation.md also contains listen_addr, but in a tracing-subscriber log line, not a /config body.

Guard

A unit test compares each sample's top-level key list against the body build_config_json / build_health_json actually builds — set and order in one assertion — and separately checks that nested objects ascend, which is the only reach it has into a plugins block an empty PluginManager cannot produce.

Six mutants were run to confirm the test earns its place; each reddens on its intended assertion:

The last is the drift that produced this in the first place: a key added to the code with the samples left behind.

Verification

• cargo fmt -- --check, cargo clippy --no-default-features --all-targets -- -D warnings — clean
• cargo test --no-default-features and with plugin-apm,plugin-async,plugin-profiler,plugin-shared — 1863 passed, 0 failed
• scripts/gen-llms-txt.sh --check — up to date (58 pages); llms-full.txt is regenerated, not hand-edited
• Every reordered block parses as JSON, and each one compares equal in value to its pre-change version — only the text ordering moved