refactor(config): separate core and backend tool options

[risu729]

Summary

• Introduce CoreToolOptions, RawBackendOptions, and ToolOptions while keeping ToolVersionOptions as a compatibility alias.
• Store mise-owned control-plane options under CoreToolOptions and backend-specific TOML values under RawBackendOptions.
• Move call sites that need the raw backend map to explicit backend option accessors.
• Update test fixtures/snapshots and add a serde invariant test that core keys do not leak into raw backend options.

Behavior changes

• None intended or found during review. This is a refactor of internal option storage/access; config parsing, option merging, version rewriting, backend option serialization, and install behavior should remain unchanged.
• Snapshot updates reflect internal Debug type names only: ToolOptions, CoreToolOptions, and RawBackendOptions.

Review fixes

• The lenient parser skips only invalid core options instead of dropping all backend options.
• Template normalization does not rewrite core option values.
• The supported scalar error message for core option parsing lists datetime values.
• A parser-contract doc comment explains why some install-time scalar keys are validated by the core parser but stored in raw opts.

Tests

• cargo test --all-features tool_version_options
• cargo check --all-features

[gemini-code-assist]

Code Review

This pull request refactors tool options by splitting them into CoreToolOptions (for mise-specific fields like os, depends, and install_env) and RawBackendOptions. It introduces a new ToolOptions struct, centralizes option parsing logic, and updates backends and configuration handling to use this structured approach. Feedback includes a suggestion to update an error message in src/toolset/tool_version_options.rs to correctly list datetime as a supported scalar type for core options.

[greptile-apps]

Greptile Summary

This PR splits the monolithic ToolVersionOptions struct into two clearly-scoped types — CoreToolOptions (mise-owned control-plane fields: os, depends, install_env) and RawBackendOptions (a newtype over IndexMap<String, toml::Value> for backend-specific values) — unified under ToolOptions, with ToolVersionOptions kept as a type alias for compatibility.

• All existing call sites are updated to use explicit accessors (backend_options(), into_backend_options(), .core.*) or the Deref-into-CoreToolOptions shorthand; snapshot files are updated to reflect the new Debug type names.
• A new serde invariant test (test_serde_splits_core_and_backend_options) verifies that deserialization correctly routes named core keys into CoreToolOptions and leaves the rest in RawBackendOptions.values, confirming the double-#[serde(flatten)] design works as intended with the toml crate.
• The lenient option parser now skips only invalid individual core keys rather than discarding all options on first error, and template normalization is guarded by should_normalize_option_template so core field values are not rewritten.

Confidence Score: 5/5

Pure internal refactor with no observable behavior changes; all call sites updated, snapshots regenerated, and new serde invariant test added. Safe to merge.

Every changed file is a mechanical update of field access patterns or test fixtures. The one structural decision — two #[serde(flatten)] fields in ToolOptions — is validated end-to-end by the new test_serde_splits_core_and_backend_options test using the real toml deserializer. No logic changes were made to option routing, merging, or backend installation paths.

No files require special attention.

Important Files Changed

Filename	Overview
src/toolset/tool_version_options.rs	Core of the refactor: introduces CoreToolOptions, RawBackendOptions, and ToolOptions; adds Deref impls, serde invariant test, and doc comments. Logic appears correct and well-tested.
src/config/config_file/mise_toml.rs	Updated insert_core_options to unpack options.core first; should_normalize_option_template guards template rewriting so core fields are not transformed.
src/backend/vfox.rs	Call sites updated to use into_backend_options().into_map() and backend_options().as_map() instead of .opts direct field access; changes are mechanical and correct.
src/backend/asdf.rs	Single accessor update from .options().install_env to .options().core.install_env; straightforward and correct.
src/registry.rs	Wraps bare IndexMap with RawBackendOptions::from(opts) when constructing ToolVersionOptions; correct mechanical update.
src/cli/tool_stub.rs	Construction of ToolVersionOptions migrated to explicit CoreToolOptions { os, depends, install_env } struct; correct.
src/backend/spm.rs	Test fixtures updated to use .into() to convert bare IndexMap literals to RawBackendOptions; correct.
src/backend/static_helpers.rs	Eight identical test-fixture updates: opts → opts.into() to satisfy the new RawBackendOptions type; all correct.
src/toolset/mod.rs	Re-exports CoreToolOptions, RawBackendOptions, ToolOptions from the new type definitions; correct.
src/config/mod.rs	Return types of get_tool_opts and get_tool_opts_with_overrides changed from ToolVersionOptions to ToolOptions; since the two are now a type alias this is a rename only.

_{Reviews (4): Last reviewed commit: "docs(config): clarify tool option parser..." | Re-trigger Greptile}

[risu729]

Greptile nit note: I checked the latest review note about a dead EPHEMERAL_OPT_KEYS entry. I am leaving the entries in place because they are still a defensive/legacy filter for raw option maps that can come from older manifests/cache data or manual construction, even though current parsing routes depends and install_env into CoreToolOptions. The actionable Gemini and Greptile line threads have been applied, replied to, and resolved.

This comment was generated by an AI coding assistant.