Address PR feedback: widen release fixtures + drop speculative dev0 mapping

Two follow-ups on #1317 review:

1. Ting: "这个地方为什么有一个 dev0？"
   `_PACKAGE_TO_SCHEMA["2026.1.28.dev0"]` was speculative - no such tag
   exists in git and `get_ver_git.py`'s scheme never surfaces `.dev0` as
   a release identifier a user would type. Removed. If a future user
   types a PEP 440 dev/post suffix we'd rather show the clear
   "no handler registered" dispatch error than silently remap.

2. Ting: "这个地方应该把之前发过的所有版本的 YAML 文件全都拿进来,
   对不对?"
   Vendored every formal supy release sample_config verbatim:
     * 2025.10.15 + 2025.11.20 - identity path (both parse directly
       under the current validator)
     * 2026.1.28 - upgrade path via the pre-setpoint-split handler
       (already present)
     * 2026.4.3 - identity path (already present)
   Rationale: regression guards for the whole migration surface, not
   just "last release". If a future schema change breaks any of them,
   CI fires immediately and either a new handler lands or the fixture
   refresh goes through with a justifying commit, per the existing
   README policy.

README rewritten to describe the fixture taxonomy per formal tag with
identity / upgrade-path annotations.

Test results:
  * test_release_compat.py: 4 release fixtures (2025.10.15, 2025.11.20,
    2026.4.3 identity; 2026.1.28 upgrade) + 3 docs examples all pass
  * test_yaml_upgrade.py: 13 passed (module + CLI + handler)

Refs #1301, #1304.

Author: sunt05

CHANGELOG.md

@@ -62,8 +62,8 @@ EXAMPLES:
   - Loader drift hint in `SUEWSConfig.from_yaml` updated to `suews-convert -i <old.yml> -o <new.yml> [-f <release-tag>]`
 - [feature][experimental] Register `2026.1.28 -> 2025.12` YAML upgrade handler (#1304)
   - New handler `_migrate_pre_setpoint_split_to_2025_12` in `src/supy/util/converter/yaml_upgrade.py` migrates profile-shaped `HeatingSetpointTemperature` / `CoolingSetpointTemperature` fields (pre-#1261) into the post-split `*Profile` + scalar pair, and sets `model.physics.setpointmethod = 2` (SCHEDULED) to preserve the user's profile intent
-  - Added vendored release fixture `test/fixtures/release_configs/2026.1.28.yml` (captured from tag `2026.1.28`) and a new `TestReleaseCompat.test_pre_drift_release_upgrades_and_parses` guard that asserts every pre-drift fixture upgrades cleanly and then parses under the current validator
-  - Retrofit schema label `2026.1` for pre-#1261 YAMLs; registered in `_PACKAGE_TO_SCHEMA` for release tags `2026.1.28` and `2026.1.28.dev0`
+  - Vendored every formal supy release sample_config under `test/fixtures/release_configs/` (`2025.10.15`, `2025.11.20`, `2026.1.28`, `2026.4.3`); `test_release_compat.py` now covers identity-path fixtures alongside the `2026.1.28` pre-drift upgrade regression
+  - Retrofit schema label `2026.1` for pre-#1261 YAMLs; registered in `_PACKAGE_TO_SCHEMA` for release tag `2026.1.28`
 - [maintenance] Split CI matrix on the physics/api marker axis (#1300)
   - `CIBW_TEST_COMMAND` now runs `-m "physics and <tier>"` on the build Python only; physics tests are binary-determined, so one run per `(OS, arch)` is sufficient
   - New reusable workflow `test-api-cross-python-reusable.yml` runs `-m "api and <tier>"` across the cross-CPython matrix (BOOKEND for PRs, ALL for nightly/tag); picks up the Python wrapper surface variations that vary per interpreter

src/supy/util/converter/yaml_upgrade.py

@@ -28,16 +28,16 @@
 # they shipped with. Extend when a release bumps `CURRENT_SCHEMA_VERSION`.
 # ---------------------------------------------------------------------------
 
-# Pre-#1261 releases (2026.1.x, 2026.2.x, 2026.3.x) labelled their shape
-# under the same `2025.12` schema umbrella but used the pre-split
-# `HeatingSetpointTemperature` / `CoolingSetpointTemperature` profile-shaped
-# fields. We retrofit a dedicated `2026.1` schema label so the dispatch can
-# distinguish those YAMLs from the post-#1261 shape that ships in 2026.4.x.
+# The `2026.1.28` release shipped the pre-#1261 setpoint shape under the
+# same `2025.12` schema umbrella, so we retrofit a dedicated `2026.1` schema
+# label for the dispatch to distinguish it from the post-#1261 shape. Older
+# formal releases (`2025.10.15`, `2025.11.20`) and the post-split
+# `2026.4.3` sample configs still parse directly under the current
+# validator - no package-to-schema remap needed for them.
 _SCHEMA_PRE_SETPOINT_SPLIT = "2026.1"
 
 _PACKAGE_TO_SCHEMA: dict[str, str] = {
     "2026.1.28": _SCHEMA_PRE_SETPOINT_SPLIT,
-    "2026.1.28.dev0": _SCHEMA_PRE_SETPOINT_SPLIT,
     "2026.4.3": "2025.12",
 }