feat(config): support lithos.toml as a first-class project config

[siriuslatte]

What to build

Add lithos.toml as a first-class project config format alongside YAML and JSON.

Lithos already supports lithos.yml, lithos.yaml, and lithos.json, but TOML would be a strong fit for people who prefer sectioned configuration with explicit tables such as [target.experience], [state.remote], and [[environments]].

The useful part of TOML here is not just another extension. TOML gives the project shape a more structured, section-oriented feel, which could make larger configs easier to scan and edit. That matters especially for nested Lithos config like environments, targets, outputs/codegen, and remote state.

This should be treated as a real config-format design task, not just a parser swap. Lithos has enum-like and nested shapes that are currently documented in YAML/JSON terms, so TOML support needs a clearly defined mapping for those same config structures.

Recommended direction

Define a canonical TOML representation for the existing Config shape and support it through the same project-loading pipeline as YAML and JSON.

The obvious examples are:

• [[environments]] for environment entries
• [target.experience] and deeper nested tables for target configuration
• [state.remote] for remote state configuration
• [outputs] or [codegen] for outputs defaults

That mapping should be documented as the preferred TOML form rather than leaving users to guess how every nested structure or tagged object should be written.

Acceptance criteria

• Running a Lithos command with no PROJECT argument or with a directory path can discover lithos.toml in a documented, deterministic search order.
• Passing an explicit PROJECT path to lithos.toml works consistently across commands.
• Lithos defines and documents a canonical TOML mapping for the current config schema, including nested tables and repeated sections like [[environments]].
• TOML parsing uses the same underlying Config shape and validation rules as YAML and JSON.
• Error messages mention lithos.toml when config discovery fails or when TOML parsing/validation fails.
• Docs include at least one real TOML example showing the table-based style, not just a note that TOML exists.
• Editor/schema guidance is documented for TOML users where practical, even if the setup differs from YAML/JSON.
• Tests cover directory discovery, explicit-file loading, precedence behavior, and representative TOML parsing cases.

Out of scope

• Supporting ad-hoc TOML shapes that do not map cleanly to the existing config schema.
• Changing the underlying config model just to make TOML syntax shorter.
• Rewriting existing YAML or JSON configs automatically.
• Adding computed/runtime config behavior; this issue is for static TOML config support.