[BUG] git clone from bundle with --all does not fetch all refs

# Problem with git bundle --all and git clone for air-gapped transfer to offline environments

## Description

When creating a bundle using `git bundle create --all`, all refs including `refs/remotes/origin/*` are included in the bundle. However, when cloning from this bundle using `git clone`, these remote refs are not automatically fetched, making many branches inaccessible.

## Steps to Reproduce

1. In a repository with multiple branches and remote tracking branches (e.g., after cloning from GitLab/GitHub)
2. Create a bundle: `git bundle create repo.bundle --all`
3. Verify bundle contents: `git bundle list-heads repo.bundle` (shows both `refs/heads/*` and `refs/remotes/origin/*`)
4. Clone from bundle: `git clone repo.bundle cloned-repo`
5. Check available branches: `cd cloned-repo && git branch -a`

## Expected Behavior

All refs included in the bundle (both `refs/heads/*` and `refs/remotes/origin/*`) should be accessible after cloning. Users should be able to see and checkout all branches that were in the original repository.

## Actual Behavior

Only refs under `refs/heads/*` in the bundle become remote tracking branches. Refs stored as `refs/remotes/origin/*` in the bundle are not fetched during clone, making these branches inaccessible without manual intervention.

## Workaround

After cloning, manually fetch the remote refs:

```bash git fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*' ```

## Impact

This breaks the expected workflow for distributing complete repository snapshots via bundles (e.g., for offline environments). Users expect `git bundle --all` followed by `git clone` to preserve all branches.

The `--all` flag documentation states it includes "all refs", but the cloning behavior does not match this expectation. This creates a surprising and unintuitive user experience when bundles are used for offline repository distribution.

## Environment

[System Info] git version: git version 2.45.2.windows.1 cpu: x86_64 built from commit: 91d03cb2e4fbf6ad961ace739b8a646868cb154d sizeof-long: 4 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Windows 10.0 26100 compiler info: gnuc: 14.1 libc info: no libc information available $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe

## Suggested Fix

One of the following approaches could address this issue:

1. **Automatic fetch during clone**: `git clone` should automatically fetch all refs present in a bundle, including `refs/remotes/origin/*`, OR

2. **Bundle creation remapping**: `git bundle create --all` should convert `refs/remotes/origin/*` to `refs/heads/*` so they're properly restored during clone, OR

3. **Documentation improvement**: Document this behavior clearly in `git-bundle` and `git-clone` documentation with the workaround, including a note that `--all` does not guarantee all refs will be available after cloning without additional steps.

## Additional Context

This issue was discovered while preparing repository snapshots for developers working in offline/air-gapped environments. The workflow of `git bundle create --all` >> transfer >> `git clone` appears to be a complete solution but silently loses access to most branches.

********************************* Andrew Harmon aharmon@signalquest.com

SignalQuest - precision microsensors 10 Water Street, Lebanon, NH, 03766 (603)-448-6266 *********************************