lint: enforce that every FastLED version string agrees, and that a release tag matches them

Follow-up to #4442 / #4443.

Problem

The version is written by hand in four places, and nothing checks that they agree with each other or with the release tag:

Location	Form
library.properties	version=X.Y.Z
library.json	"version": "X.Y.Z"
src/FastLED.h	#define FASTLED_VERSION XYYYZZZ (1 + 3 + 3 digits)
release_notes.md	first heading, FastLED X.Y.Z (optionally (Next Release))

They drifted without anything noticing. Before #4443, master had library.properties = 3.10.4, library.json = 3.10.3 and FASTLED_VERSION = 3010004 while 3.10.5 was already published. Tag 3.10.4 itself shipped with library.json still saying 3.10.3. An Arduino UNO Q user who installed master correctly saw "3.10.4" in the IDE, concluded the install had not worked, and the Library Manager offered to "update" them back to a broken release.

Proposed check

1. Consistency (runs in bash lint, every PR). Parse the four locations and fail unless they all encode the same X.Y.Z, including the integer encoding of FASTLED_VERSION. Report every location and its value on failure. This is a cross-file structural check, so per agents/docs/linter-architecture.md it belongs on the Python side, not in the Rust per-file linter.

2. Not behind the latest release (same check). The shared version must be strictly greater than the highest X.Y.Z git tag that is an ancestor of HEAD — master is always the next release. Must degrade to a skip with a note, not a failure, when tags are unavailable (shallow CI clones, ZIP downloads); CI jobs that want this enforced need fetch-depth: 0 or fetch-tags.

3. Tag match (runs on tag push). A workflow triggered on X.Y.Z tags fails if the tag name differs from the in-tree version, and if the top release_notes.md heading still says (Next Release). No workflow currently triggers on version tags, so this is a new one.

Acceptance

• Reverting any single hunk of #4443's version bump makes bash lint fail and name the offending file.
• A unit test covers the parser for each of the four formats plus the integer encoding (e.g. 3.10.6 ↔ 3010006).
• Pushing a tag that disagrees with the tree fails the tag workflow.

Open question

Whether to go further and generate three of the four from one source of truth instead of linting them. Linting is the smaller change and catches the same drift; library.properties and library.json must exist as static files for the Arduino and PlatformIO registries either way.