Feature Request: Native `dry-run` or similar flag in dependabot.yml

### Is there an existing issue for this?

- [x] I have searched the existing issues

## Summary

Add a `dry-run: true` option to `.github/dependabot.yml` that executes the full Dependabot update pipeline including but not limited to:

- fetching files
- resolving versions
- computing diffs

But suppresses all outbound service calls: no PRs are opened, no branches are created. Results would be surfaced as the existing job logs

---

## Motivation

### The current alternatives require understanding Dependabot internals

Two dry-run paths exist today:

1. `bin/dry-run.rb`: a Ruby script inside `dependabot-core` aimed at
contributors debugging the library itself. Using it requires:

- Cloning `dependabot-core` and building ecosystem-specific Docker images
- Translating your `dependabot.yml` config into positional CLI arguments and
environment variables (`IGNORE_CONDITIONS`, `SECURITY_ADVISORIES`, etc.)
- Understanding internal identifiers that differ from those in `dependabot.yml`
(e.g. the ecosystem must be passed as its internal directory name like
`npm_and_yarn`, not the YAML value `npm`)

**2. The Dependabot CLI (`dependabot update`)** : a more polished tool, but
still requires users to write a separate job description file in an internal
schema that maps only loosely to `dependabot.yml`. Users must understand internal concepts that they should not have to

### The config users already have is the correct source of truth

A user who wants to test Dependabot behavior already has everything Dependabot
needs in `.github/dependabot.yml`: ecosystems, directories, schedules, ignore
rules, allowed update types, registries.

What we are asking our users today is that for `dry-run`, they follow a completely and alien workflow that can usually translates to:

- Users mis-translate their config and test the wrong thing
- Users give up and push config changes blind, discovering problems only when
unwanted PRs are opened against their repository

### Validating config changes is a common, legitimate need

Users reach for dry runs when:

- Setting up Dependabot for the first time on a large monorepo and wanting to
preview the volume and shape of PRs before enabling updates
- Tweaking `ignore` rules and wanting to confirm the right dependencies are
excluded before changes go live
- Debugging why an expected update didn't fire (or did fire unexpectedly)
- Submitting a bug report: the README itself asks that issues be reproducible
via the CLI or dry-run script which is not realistic as described above.

---

## Proposed Solution

Add a`dry-run` key to the `dependabot.yml` schema:

```yaml
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
dry-run: true # <-- new flag
schedule:
interval: "weekly"
ignore:
- dependency-name: "lodash"
versions: ["4.x"]
```

### Behavior when `dry-run: true` is set

- Dependabot executes the scans normally: all update logic executes as normal: files are fetched, versions resolved,
diffs computed
- Output is emitted to the Actions log as normal but no service call is executed

---

## Summary of the alternatives Considered

| Alternative | Why it falls short |
|---|---|
| `bin/dry-run.rb` | Requires cloning `dependabot-core`, building Docker images, and knowledge of internal package manager identifiers. Intended for contributors, not end users. |
| Dependabot CLI (`dependabot update`) | Requires Docker, a separate undocumented job description file, and understanding of internal service concepts (proxy, updater images, credential injection). Barrier is too high for routine config validation. |
| `@dependabot dry-run` comment command | Requires an existing PR to comment on; not useful for initial setup or schedule-based config validation |
| GitHub Actions wrapper workflow | Shifts the burden to users to wire up and maintain a custom workflow; not something Dependabot should require users to build themselves. |

Start by reading bin/dry-run.rb and the existing .github/dependabot.yml configuration flow to understand how current dry runs map configuration into the update pipeline. Trace where outbound service calls are made and how job logs are emitted. Done means a dry-run option uses the existing configuration, performs the update calculations, and suppresses branch and pull-request creation.

Written by the indexing model from the issue text.