revert: remove the scheduled Dependabot auto-merge workflow (#2702)

.rulesync/rules/github-actions-security.md

@@ -27,14 +27,14 @@ Reference: https://docs.github.com/ja/actions/concepts/security/script-injection
 
 Third-party GitHub Actions are pinned to a full 40-character commit SHA with a trailing `# vX.Y.Z` comment. Keep that convention when adding or bumping an action.
 
-`anomalyco/opencode/github` (used by `draft-release.yml` and `dependabot-auto-merge.yml`) is a composite action, so its SHA pin covers the wrapper only:
+`anomalyco/opencode/github` (used by `draft-release.yml`) is a composite action, so its SHA pin covers the wrapper only:
 
 - The wrapper resolves the `opencode` CLI release to `latest` at run time and installs it with `curl -fsSL https://opencode.ai/install | bash`, so the binary that actually receives the workflow secrets is not pinned by the SHA.
 - The wrapper also uses `actions/cache@v4` internally, by mutable tag.
 
-The accepted stance is to treat `https://opencode.ai/install` as a trusted install path rather than vendoring a pinned installer, because the workflows that reach it cannot be triggered by an outside contributor: `draft-release.yml` is `workflow_dispatch`-only and gated on `github.actor`, and `dependabot-auto-merge.yml` runs on a `schedule` — whose definition always comes from `main` — plus a `workflow_dispatch` carrying the same actor gate. Bumping the pin is still worthwhile for the wrapper itself, but do not read it as a guarantee about the CLI version.
+The accepted stance is to treat `https://opencode.ai/install` as a trusted install path rather than vendoring a pinned installer, because `draft-release.yml` is `workflow_dispatch`-only and gated on `github.actor`, so an outside contributor cannot trigger it. Bumping the pin is still worthwhile for the wrapper itself, but do not read it as a guarantee about the CLI version.
 
-The residual risk this stance accepts is that a compromise of the distribution endpoint would expose whatever the workflow hands the CLI — the model API keys and a `GITHUB_TOKEN` with `contents: write`, `pull-requests: write`, and `issues: write`. The `github.actor` gate limits _who can trigger_ the workflow; it does not reduce that exposure on a maintainer-triggered run, and a scheduled run has no triggering actor to gate at all. Revisit this if either workflow ever becomes externally triggerable, if the token or secret scope it receives grows, or if upstream adds a `version` input that lets the CLI itself be pinned.
+The residual risk this stance accepts is that a compromise of the distribution endpoint would expose whatever the workflow hands the CLI — the model API keys and a `GITHUB_TOKEN` with `contents: write`, `pull-requests: write`, and `issues: write`. The `github.actor` gate limits _who can trigger_ the workflow; it does not reduce that exposure on a maintainer-triggered run. Revisit this if the workflow ever becomes externally triggerable, if the token or secret scope it receives grows, or if upstream adds a `version` input that lets the CLI itself be pinned.
 
 ## OIDC Permissions