[Feature request] Separate explicit fetch mapping from default fetch selection

["Douglas Puchalski (dpuchals)" <dpuchals@cisco.com>]

Git version: 2.55.0
Environment: macOS 26.6

I configure a remote to fetch only a small default set of branches:

    [remote "origin"]
        fetch = +refs/heads/main:refs/remotes/origin/main
        fetch = +refs/heads/team/*:refs/remotes/origin/team/*

This prevents `git fetch origin` from fetching and updating a very large
number of remote branches.

When I explicitly request another branch:

    git fetch origin topic/example

Git fetches the branch into FETCH_HEAD but does not create or update:

    refs/remotes/origin/topic/example

Consequently, the natural checkout command fails:

    git checkout -b topic/example origin/topic/example

The documented behavior couples two separate policies in
`remote.<name>.fetch`:

1. Which branches an ordinary `git fetch <remote>` selects automatically.
2. Where an explicitly requested branch is stored locally.

Please provide a configuration or default behavior under which an explicitly
named remote branch is stored as the corresponding remote-tracking ref, while
the remote's automatic fetch set remains restricted.

With that behavior, this sequence would work:

    git fetch origin topic/example
    git checkout -b topic/example origin/topic/example

It should not require fetching every remote branch, repeating the branch name
in a two-sided refspec, supplying `--refmap`, defining aliases, or handing the
result between commands through FETCH_HEAD. FETCH_HEAD is shared mutable state
and can be overwritten by another fetch between commands.

A backward-compatible opt-in configuration would address existing scripts
that rely on source-only fetches remaining temporary.

Relevant documentation:
https://git-scm <https://git-scm/>.com/docs/git-fetch