feat: default syntax dropdown to "Automatic", remove TOML option (was mapped to JSON)

[luochen1990]

What

• Default the syntax <select> on the upload form to the Automatic option (client-side highlight.js auto-detection) instead of None. Pasted code gets highlighted out of the box without any manual selection; "None" remains available for plain-text pastes.
• Remove the TOML entry from the server-rendered syntax list. It was mapped to json, so selecting it silently produced JSON highlighting for TOML content.

Why

• With the current default, a paste is only highlighted after a manual syntax selection. Defaulting to Automatic removes that step, while manual override stays one dropdown away. A user asked for this on the v2 release thread (https://www.reddit.com/r/selfhosted/comments/14x36vs/microbin_v2_released — "maybe the option to have syntax highlighting by default set to client-side automatic?").

• The TOML entry cannot be fixed by pointing it at a toml extension: the syntect version pinned in Cargo.lock (5.3.0) does not ship a TOML syntax in its default set. Verified two ways against the 5.3.0 sources:

  • testdata/Packages submodule pin is fa6b862, which predates TOML being added to sublimehq/Packages;
  • the shipped assets/default_newlines.packdump (what load_defaults_newlines() actually loads) contains no toml extension, while json/yaml/rust are present as controls.

  So a toml value would resolve to no syntax in syntect 5.3.0 and render as plain text (microbin's find_syntax_by_extension(...).or_else(plain_text) fallback) — removing the entry seems clearer than keeping a value that highlights TOML as JSON. TOML pastes still get some coverage under the Automatic path (the bundled highlight.js includes an ini grammar, which partially covers TOML). TOML support has since landed in syntect's unreleased master, so the option can be reintroduced after a future syntect bump.

Alternatives considered

A configurable default (e.g. a MICROBIN_DEFAULT_SYNTAX env var wired through to the template) would be the more general solution if you prefer not to change the built-in default — happy to rework this PR in that direction. The current form keeps the diff minimal. Happy to split the two changes into separate PRs as well if you prefer.

Testing

The same change has been built as part of a self-hosted instance's packaging, derived from the v2.1.4 sources: the modified template was verified to be compiled into the binary (checked the embedded template strings in the built artifact, for both the new default and the removed entry). This PR's branch passes cargo check against current master. The touched template region is byte-identical between v2.1.4 and master, so the packaging-side verification carries over.