Say 7.4 on the PHP badge, and make CI enforce it

[matasarei]

The PHP badge read 8.1 | 8.3 | 8.4. That is the CI matrix, not what the plugin supports —
version.php declares $plugin->phpversion = '7.4.0', and sites run it there.

Now 7.4 | 8.x.

Why the badge was the smaller half of the problem

Changing the text alone would have moved the inaccuracy rather than removed it: nothing was
checking 7.4 either. The plugin claimed a minimum that no job exercised, so the claim rested
on a local php -l I happened to run during the audit.

moodle-plugin-ci v4 requires PHP 8, so the full suite genuinely cannot run on 7.4. What can:

• php -l on every file under 7.4 — catches 8.x-only syntax
• a grep guard for 8.x-only functions — str_contains, str_starts_with, get_debug_type
  and friends. php -l cannot see these: they parse fine on 7.4 and fatal at runtime, which is
  the failure mode that reaches a live site instead of a build

Both run in a new php74-syntax job. I verified the guard fires on a file containing
str_contains( and passes on the current tree.

Honesty in the README

The requirements section now says which version is tested and which is only checked:

Continuous integration runs the full suite on PHP 8.1, 8.3 and 8.4 […] PHP 7.4 gets a syntax
check and a guard against 8.x-only functions, because moodle-plugin-ci needs PHP 8 to run
and so the suite itself cannot execute there. If you run 7.4, the plugin is built for it and
checked for it, but the tests that prove behaviour run one version up.

That is a weaker guarantee than the badge implies on its own, and it should be stated rather
than left for someone to discover.

Testing

The new job runs on this PR — that is the verification. Locally: php -l clean on 7.4 and 8.1,
guard verified in both directions, workflow YAML parses with both jobs present.

Notes

• No version bump: only a comment changed in version.php.
• Does not conflict with Make the changelog's breaking list match what actually breaks #16, which touches CHANGELOG.md and the release notes.