fix: keep an upgradeable version in version.php

[amanzano3ip]

What. One line: keeps $plugin->version at the latest release plus one (2026070701) instead of the 9999999999 sentinel. $plugin->release stays 'dev' — it is informational only, does not affect upgrade logic, and preserves the existing signal that a repo checkout is development code.

Why this matters.

1. It bricks upgrades for anyone who installs from the repo. The sentinel 9999999999 is the highest value version.php can hold. As soon as it lands in a site's database (a git clone into mod/, or GitHub's "Download ZIP", both common ways people try a plugin), that site is stuck forever: every real release is a lower number, and Moodle refuses lower versions as a downgrade. There is no in-product recovery — the admin has to edit the database or uninstall/reinstall, losing data. We hit exactly this on our own test site while reviewing.
2. The Marketplace links the repo, so real users will land here. The plugin's Marketplace page points at this repository as the source. Some administrators clone or download from the source instead of the packaged ZIP; today that path silently leads to an unupgradeable install.
3. It hides which code a site is running. When a support request comes in, 9999999999 tells you nothing — not the release, not the date, not the commit. A real version number (2026070701) is traceable; the sentinel turns every "what version are you on?" into guesswork.

In short: the sentinel protects nobody at runtime but can permanently break a real site and complicate support. Committing a real, ever-increasing version removes that failure mode at zero cost to the release process.

What does NOT change. The packaging flow is untouched: make package still stamps the final YYYYMMDDXX and the git tag on the ZIP copy, exactly as today (scripts/package.sh). Released packages are byte-identical to the current flow's output.

Trade-off. Maintenance cost of bumping one line when a release is cut (or leaving it — the stamp always wins in packages).

Testing. Install from a repo checkout → site registers 2026070701; install the next release ZIP on top → clean upgrade (no downgrade error).

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.48%. Comparing base (5005c4a) to head (1f3ba6d).

Additional details and impacted files

@@            Coverage Diff            @@
##               main     #100   +/-   ##
=========================================
  Coverage     89.48%   89.48%           
  Complexity      979      979           
=========================================
  Files            52       52           
  Lines          4221     4221           
=========================================
  Hits           3777     3777           
  Misses          444      444           

Flag	Coverage Δ
javascript	94.03% <ø> (ø)
php	89.31% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
PHP (server-side)	89.31% <ø> (ø)
JavaScript (SCORM tracker)	94.03% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[erseco]

Superseded by #111, which keeps this PR's core diagnosis — the 9999999999 sentinel bricks checkout installs — and completes it: 2026070701 is lower than the 2026072400 savepoint that now exists in db/upgrade.php, so the minimum valid development version became 2026072401. PR 111 also removes the packaging date dependency (the ZIP ships version.php byte-identical to the committed file), moves release metadata to a release-preparation PR committed before tagging, and adds scripts/check-version.sh + CI enforcement (ADR DEC-0068, superseding DEC-0030). Closing in favour of that PR — thank you for catching and demonstrating the underlying problem.