GA: upgrade-test matrix 0.30 -> 1.0 + downstream rebuild smoke

[justinjoy]

Why (block)

#687 lists artefact production but does not require evidence
that the artefact actually works as a stable-API drop-in for
existing consumers. A 1.0 stable-API claim without an
upgrade-matrix is unverifiable.

Scope

• Upgrade-test matrix:
  • Build a small set of synthetic consumer programs (one
    using wl_easy, one using wirelog_session_*, one
    using wirelog_executor_t).
  • For each, link against:
    • v0.30.0 (the most-recent shipped release).
    • The 1.0.0 candidate tarball.
  • Verify:
    • Each program builds against both versions (with the
      documented migration recipes from docs/MIGRATION.md,
      see docs/MIGRATION.md: validate and consolidate 0.30 -> 1.0 migration entry #745).
    • Each program produces the same gold output against
      both versions.
• Downstream rebuild smoke:
  • Pull each existing benchmark workload's .dl source
    (DOOP, CSPA, Polonius, Galen, DDISASM, CRDT).
  • Rebuild and run against the tagged 1.0.0 candidate.
  • Assert tuple counts and iteration counts match the
    docs/PERFORMANCE.md snapshot.

Acceptance

• tests/upgrade/<consumer>/ directory contains the synthetic
  programs.
• Upgrade test runs in the at-tag CI workflow (B19: at-tag CI re-verification of full matrix (Tier-1 + abi + sanitizer + perf) #749 B19) and
  blocks the release if it fails.
• Smoke matrix recorded as a release-notes appendix.

Cross-ref: #687, #745 MIGRATION 0.30 -> 1.0, #699 B12,
#714 C11.