docs(ci): record that security updates ignore target-branch

[DemchaAV]

Why

The comment beside the release-smoke directories in .github/dependabot.yml
explained #514 landing on main as a consequence of those paths sitting
outside every listed directory. That reads as though listing them — which
#517 did — stops it happening again. It does not.

Dependabot raises security updates against the default branch whatever
target-branch says. GitHub states it in the options reference: setting
labels "will also affect pull requests for security updates to the manifest
files of this package manager, unless you use target-branch to check for
version updates on a non-default branch", and commit-message carries the
same carve-out. #514 is the observable form of the branch half — a security
update, and the only Dependabot PR ever opened for these manifests, landing
on main while this file says develop.

So the divergence this entry exists to prevent will recur on the next
advisory, and the file currently tells the next reader it cannot.

What

Replaces the wrong cause with the rule and the handling it implies: close
the PR and carry the bump to develop rather than merging it, so main
stays a fast-forward of develop — which is what #517 did.

Also records that a non-default target-branch exempts security updates
from the labels and commit-message settings, so those PRs arrive under
Dependabot's defaults and will not match the house style.

The second commit corrects a claim inherited from the comment being
replaced. It called the eight release-smoke projects "deliberately identical
setups"; they are deliberately different — one per published coordinate
combination (wrapper, lean core, core plus each render backend, templates,
testing, bundle), with s2 additionally running an enforcer dependency-tree
assertion the others do not. Read literally the old wording invites
consolidating them, which would delete the coverage they exist to provide.
What is identical is the test scaffolding — junit, assertj and surefire
pinned separately in all eight — and that is the real reason a bump has to
be applied eight times.

Comments only. No option value changes.

Tests

Nothing in the build reads dependabot.yml, so there is no guard to extend
and none was added. A guard could assert the file parses and the keys exist,
but every claim here is about GitHub's behaviour, which no local test can
exercise — it would restate the file to itself and stay green whether or
not the prose is true, which is the failure mode that produced the wrong
comment in the first place.

Verified by parsing the file and asserting every option survived both edits:
version, the four directories entries, target-branch: develop,
labels, commit-message, and both ecosystem entries are byte-for-byte
what they were. git diff is confined to the comment blocks.