`group-by: dependency-name` PRs cannot be rebased — always fails with "unknown group"

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Package ecosystem

`docker`, `pip`, `gitsubmodule` (reproduced across all three)

### Package manager version

N/A — this is a Dependabot configuration issue, not package-manager-version-specific.

### Language version

N/A

### Manifest location and content before the Dependabot update

_No response_

### dependabot.yml content

```yaml
updates:
- package-ecosystem: "docker"
directories:
- "/src/**/*"
groups:
docker-dependencies:
patterns:
- '*'
group-by: dependency-name
schedule:
interval: "weekly"

- package-ecosystem: "gitsubmodule"
directory: "/"
groups:
gitsubmodule-dependencies:
patterns:
- '*'
group-by: dependency-name
schedule:
interval: "weekly"

- package-ecosystem: "pip"
directories:
- "/src/**/*"
- "/tests/**/*"
groups:
pip-dependencies:
patterns:
- '*'
group-by: dependency-name
schedule:
interval: "weekly"
```

### Updated dependency

_No response_

### What you expected to see, versus what you actually saw

**Expected**: Dependabot creates one PR per dependency (across all matching directories) and can rebase those PRs when the target branch is updated.

**Actual**: Every PR created by `group-by: dependency-name` becomes permanently stuck. Attempting any rebase posts the following comment and stops:

> Sorry, the `'unknown'` group has been removed from your config so we do not know how to rebase this PR.

The PRs are never rebased. They can only be closed manually and recreated.

## Steps to reproduce

1. Configure any `package-ecosystem` with `directories` and a group using `group-by: dependency-name`.
2. Wait for Dependabot to create bump PRs.
3. Push a commit to the target branch (or trigger a rebase any other way).
4. Observe: every Dependabot PR created by that group posts the `'unknown'` error and does not rebase.

## Root cause analysis

### Dynamic sub-group naming

When `group-by: dependency-name` is set, Dependabot creates **dynamic sub-groups** at PR-creation time, named `/`. For example, a group called `docker-dependencies` produces sub-group names like:

- `docker-dependencies/nginx`
- `docker-dependencies/python`

These sub-group names are stored in the PR metadata as `dependency-group-name`.

### Rebase lookup fails

When a rebase is triggered, `RefreshGroupUpdatePullRequest` reads `job.dependency_group_to_refresh` from the PR metadata (e.g. `"docker-dependencies/nginx"`) and calls:

```ruby
# dependency_snapshot.rb
def job_group
return nil unless job.dependency_group_to_refresh
@dependency_group_engine.find_group(name: T.must(job.dependency_group_to_refresh))
end
```

`find_group` searches only top-level group names from the current `dependabot.yml`. It will never find `"docker-dependencies/nginx"` because only `"docker-dependencies"` exists in config. The sub-group name is a **runtime construct** that is never written to the config file.

### The `'unknown'` fallback

When `job_group` is `nil`, the guard in `refresh_group_update_pull_request.rb` fires:

```ruby
unless dependency_snapshot.job_group
Dependabot.logger.warn(
"The '#{job.dependency_group_to_refresh || 'unknown'}' group has been removed from the update config."
)
service.capture_exception(error: DependabotError.new("Attempted to refresh a missing group."), job: job)
return
end
```

If `dependency_group_to_refresh` is set to the sub-group name, it will appear in the message verbatim. If it is nil for any reason, the fallback produces `'unknown'` — which is the exact text reported in the PR comment.

In both cases, the rebase is silently abandoned.

## Related

- [PR #14289](https://github.com/dependabot/dependabot-core/pull/14289) — "Add PR message formatting for dependency-name groups" (merged Feb 2026). This PR explicitly acknowledges that `group-by: dependency-name` creates dynamic sub-groups named `/`, and fixes their PR titles/bodies. It does **not** address the rebase failure.
- [Docs: `group-by`](https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups) — states the only accepted value is `dependency-name` and that it applies to configurations with multiple directories.

## Suggested fix

`find_group` (or the caller in `dependency_snapshot#job_group`) should check whether the stored group name is a sub-group reference in the form `/`. If so, it should strip the suffix and look up the parent group instead, so the rebase job can be associated with the correct `DependencyGroup` from config.

Alternatively, the sub-group name stored in PR metadata should be the parent group name, with the dependency name stored as a separate field, so the existing lookup continues to work without modification.

### Native package manager behavior

N/A

### Images of the diff or a link to the PR, issue, or logs

_No response_

### Smallest manifest that reproduces the issue

```yaml
version: 2
updates:
- package-ecosystem: "pip"
directories:
- "/app"
- "/tests"
groups:
all-pip:
patterns:
- '*'
group-by: dependency-name
schedule:
interval: "weekly"
```

With at least one shared pip dependency across `/app` and `/tests`, Dependabot will create a PR with `dependency-group-name: "all-pip/"`. That PR cannot be rebased.