Let the plugin maintain itself, up to the point of release

[SPIKESPIGEL404]

Three triggers, one rule: a pull request that passes its checks merges
itself, and the only step a person performs is cutting a release.

The policy the agent works under lives in
bitrouter/.github#1 — three
copies of a prompt is three behaviours. The install and test commands, which
are genuinely this repository's, stay here.

on-bitrouter-release.yml

Watches the gateway this plugin talks to. The dispatch from
bitrouter/bitrouter arrives within seconds of a release; the weekly schedule
is the backstop that notices when one never did, because a token expiring
quietly is exactly the failure a fast path cannot report on itself.

Both converge on .github/upstream.json, so whichever gets there first, the
other does nothing. The agent stamps that file whatever it concludes —
which turns "we looked and nothing was needed" from a silence into a recorded
fact, and stops the weekly poll asking again forever.

The brief is narrow on purpose. This plugin is coupled to the gateway's HTTP
surface and nothing else — no binary, no version pin, no download — so the
agent is told to act on /v1/* changes and to ignore the routing engine, the
TUI, config handling, and telemetry, which move constantly and never reach
this package. It's also told that the models-endpoint shape has its own daily
watcher and not to duplicate that work.

on-harness-update.yml

Runs only when CI has already said no.

The question a harness bump raises — is this package still compatible — has a
cheaper and more reliable answer than an agent's opinion: the build typechecks
against the new types and the suite exercises the contracts under them. A green
bump needs nobody, and under auto-merge it merges itself. So the agent runs
where the cheap answer runs out, and its job is repair rather than assessment.
It pushes onto the Dependabot branch, so the bump and its fix arrive as one
reviewable thing.

workflow_run rather than pull_request_target: it runs from the default
branch, so the workflow definition and the secrets it sees are this
repository's own and never the pull request's.

It matches on the bumped package name, not on Dependabot's label. The label
would not have worked — npm allows one update entry per directory, so every npm
bump here carries harness-update whether or not it is one.

automerge.yml

Enables auto-merge and nothing else; GitHub still decides, when the required
checks pass. It withholds for needs-human, and applies that label to an
automated PR editing both src/ and test/ — the one case where "the tests
pass" is circular reasoning.

Before merging

• PLUGIN_AGENT_TOKEN and BITROUTER_API_KEY as repo secrets.
• bitrouter/.github#1 merged first — the uses: references resolve against
  its main.
• A repository_dispatch or schedule trigger only fires from a workflow on
  the default branch, so none of this runs until it's merged.

Branch protection with required checks is already in place, which is the
precondition that makes auto-merge a gate rather than a rubber stamp.

One thing found while wiring this up

Dependabot was never applying the harness-update label — it doesn't create
labels that don't exist, and this one didn't. Every Dependabot PR in this repo
has an empty label set. The label now exists, so future bumps will carry it;
open ones won't retroactively.