## What

- Add a shared backend option resolver that preserves where each
effective option came from.
- Resolve backend options in this order, with later layers overriding
earlier ones:
  1. Registry backend defaults.
2. Backend alias `[...]` options from `[tool_alias]` / `[alias]` backend
entries.
  3. Config options selected by the existing tool config lookup rules.
4. Inline backend options from the current tool spec, such as
`tool[...]`.
- Apply that resolved option path consistently in GitHub/GitLab/Forgejo,
HTTP, S3, UBI, vfox backend plugins, Conda channel resolution, SPM
provider/API URL resolution, Java release type listing, versions-host
cache filtering, fuzzy version matching, `minimum_release_age` handling,
runtime args, and install request initialization.
- Preserve inline backend options across the short-name backend cache,
so commands like `ls-remote 'github:owner/repo[api_url=...]'` do not
accidentally use a cached installed backend without those inline
options.
- Preserve config options when runtime args include inline overrides,
while still letting inline options win for the one command.
- Switch Go install to use the resolved request options.
- Fix shorthand parsing for URL-valued inline options such as
`tool[api_url=https://example/api/v3]`.

## Follow-up

The versions-host behavior for locally overridden backend options has
been split into #9568. That PR is stacked on this one and should be
rebased after this merges.

## Relationship to #9315

This PR does not change which config entry is eligible for a tool. That
behavior comes from #9315:

- Registry short names should not inherit config from their resolved
full backend key.
- Configured aliases can fall back to resolved full-backend config when
there is no alias-specific entry.
- Alias-specific `[tools.<alias>]` config is more specific than
`[tools."<resolved-backend>"]` config.

This PR builds on that lookup and changes what happens after config has
been selected: registry defaults, backend alias options, config options,
and inline options are merged through one resolver, with provenance
retained for callers that need to distinguish where an option came from.

## Relationship to #8902

#8902 was a narrower `ls-remote` fix for inline backend options. This PR
covers the same installed-tool cache failure mode generically: when a
caller supplies inline backend options, mise builds a backend from that
caller `BackendArg` instead of returning a short-name cache entry that
was loaded from install state without the inline options.

## Example

Given config selected through an alias fallback:

```toml
[tool_alias]
hw = "github:jdx/mise-test-fixtures[api_url=https://api.github.com]"

[tools."github:jdx/mise-test-fixtures"]
version = "1.0.0"
asset_pattern = "definitely-not-a-real-hello-world-asset"
```

Inline options should still win for this invocation:

```sh
mise install 'hw[asset_pattern=hello-world-1.0.0.tar.gz,bin_path=hello-world-1.0.0/bin]@1.0.0'
```

Before this PR, the resolved full-backend config could replace the
inline `asset_pattern`, and alias `[...]` options were only visible as
part of a resolved string. After this PR, alias options are their own
layer and inline options are applied over the selected config options.

## Why

Backend-level code had several config-or-inline branches. Depending on
the path:

- Inline options could be ignored when config existed for the same tool
or resolved backend.
- Inline options could be dropped at the installed-tool backend cache
boundary.
- Config options could be dropped when runtime args included inline
options.
- Backend alias `[...]` options were not represented as a distinct
layer.
- Backend-specific list/install paths could read raw backend args
instead of the resolved tool options.
- Registry defaults were not always part of the same overlay path as
config and inline options.

This PR centralizes that overlay so config-aware paths use the same
precedence, while preserving source information separately from the
effective option values.

## Validation

- `cargo fmt --all`
- `git diff --check`
- `cargo test --all-features tool_opts`
- `cargo test --all-features opts_with_config`
- `cargo test --all-features test_git_provider_from_ba`
- `mise run test:e2e e2e/backend/test_github_ls_remote_inline_opts`

*This PR was updated by an AI coding assistant.*

---------

Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>