ci: fast on branches, exhaustive on the develop → main door

[serialexperimentslainnnn]

Makes the pipeline fast where it iterates and exhaustive where it promotes.

The gate, after this PR

	Branches / PR → develop	PR develop → main
JVM tests	✅ required	✅ required
Frontend tests	✅ required	✅ required
Static analysis	—	✅ required
Dependency audit	—	✅ required
Plugin verifier	—	✅ required
Build plugin	—	✅ required
CodeQL ×2	—	✅ required

A branch iterates in ~3 minutes instead of ~13. Nothing reaches main without all eight, and
release.yml then re-runs the whole gate on the exact tree it publishes, behind the environment approval.

Required checks move with the jobs, because they have to: a required check whose job never runs is
never reported, and the pull request would wait forever. Both rulesets are updated and already applied.

Duplicated work removed

Measured, not assumed:

Duplication	Cause
Every commit ran the pipeline twice	push and pull_request both fire, and the concurrency group keyed on github.ref differs between them, so neither cancelled the other
Superseded runs kept going	cancel-in-progress applied only to pull requests
The JVM suite ran twice	koverVerify depends on :test and lived in a separate job
The plugin was built twice	verifyPlugin already produces the distributable

The last one was also subtly wrong: the artifact assertions ran against bytes that were never verified.
They now run on the verified artifact.

develop no longer requires branches to be up to date

strict_required_status_checks_policy meant every merge into develop invalidated every other open PR
and forced a full re-run. With grouped Dependabot PRs that made releasing impractical.

It is dropped only where a second net exists: CI runs on every push to develop, so a semantic conflict
between two separately-green PRs is caught there, before anything reaches main. main keeps the
strict policy — one merge per release, and it is the merge that publishes.

Caches

Read-only now applies to pull requests from forks only; every other branch writes its own cache.
Verified against GitHub's documentation rather than assumed: "Workflow runs cannot restore caches created
for child branches or sibling branches", and a cache created on a pull request is written to the merge ref
and "can only be restored by re-runs of the pull request". A topic branch cannot reach what develop
reads back — the isolation is the platform's, not ours.

Dependabot

Monthly instead of weekly, grouped per ecosystem, with an explicit applies-to: security-updates group —
security updates ignore open-pull-requests-limit entirely and were not covered by the existing group,
which is how five arrived at once under a limit of three.

Majors are no longer bot-proposed in any ecosystem. They are where a bump actually breaks something and
where CI is not sufficient on its own: the platform-plugin 2.16 → 2.18 attempt passed CI and hung the
headless suite locally, inside the platform's own test fixture.

Costs, stated rather than left to be discovered

• A formatting, detekt, ESLint or coverage failure now lands on develop and is fixed by a follow-up
  commit, instead of being caught in the pull request. That happened today with spotlessKotlinGradleCheck,
  and the PR is what caught it. The plan is to run these locally before pushing.
• The dependency audit no longer runs on the Dependabot PR that proposes a bump — it runs once that bump is
  on develop, and again before it can reach main. Nothing ships un-audited; the finding arrives one
  merge later.
• Binary incompatibilities are caught after merging into develop rather than at PR time.

Still open

• develop.json allows ["squash", "merge"]. Squash is disabled at repository level so it cannot be used
  today, but the two layers disagree — and a squash destroys the author's hardware-backed signatures.
• ADR 0001 still describes the tag-triggered release flow and needs superseding.