Unfreeze the linter pin, and add the workflow that keeps it moving

[oblomov-dev]

The pin was frozen, and the range made it permanent

npm ci reads package-lock.json, and the lock here sat at
@abap2ui5/linter 0.2.2 while two releases went by. That was not a missed
week — ^0.2.2 means >=0.2.2 <0.3.0, so 0.3.0 could not arrive even through
a fresh npm install, and nothing in this repository was ever going to move
it. Sibling samples-controls has run 0.3.0 since its release and moves
weekly.

The gate stayed green the whole time. That is the part worth naming: a green
check-abap2UI5 here and a green one there were checking different things, and
nothing said so.

What this does

• moves the lock and the range to 0.3.0;
• brings @abap2ui5/render-runtime along, deliberately — the two are one
  release with one version (the linter's metadata snapshot is generated from
  exactly the @openui5 version pinned over there), so bumping one alone is
  precisely the drift that splitting them was allowed on condition of avoiding;
• adds bump-linter.yaml, samples-controls' workflow adapted to this
  repository's own gate: weekly, tracking latest rather than the declared
  range, and running npm run check:abap2ui5 over the full corpus before
  the PR exists, so a rule regression fails the bump instead of landing on main.

Scheduled at 06:47 Mondays, after samples and samples-controls, so the
three corpora move in a known order.

Verified

npx abap2ui5lint on 0.3.0 over the full corpus:

gates      properties 32 files, render 37 documents
findings   none
abap2ui5-linter: 32 files, 0 failing, 0 skipped

Also run against the linter's main (92 rules, five of them not yet
published) — likewise clean, so nothing here is waiting on the next release
either.

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.