Add YAML 1.2.2 Chapter 2 spec-compliance test harness

[MariusStorhaug]

Why

Tracking YAML 1.2.2 spec coverage needs a single visible scoreboard so contributors can see what's supported today and what's deferred to a follow-up issue.

What

Add tests/Spec-1.2.2.Tests.ps1 with one Pester It per example from YAML 1.2.2 spec Chapter 2. Each test name includes the example number and title (e.g. Example 2.4 - Sequence of Mappings). Tests for examples that already pass run; tests for unsupported examples are marked -Skip with a comment referencing the tracking issue.

Scoreboard

#	Title	Status	Tracked by
2.1	Sequence of Scalars	✅ supported	—
2.2	Mapping Scalars to Scalars	✅ supported	—
2.3	Mapping Scalars to Sequences	✅ supported	—
2.4	Sequence of Mappings	✅ supported	—
2.5	Sequence of Sequences (flow)	❌ deferred	#7
2.6	Mapping of Mappings (flow)	❌ deferred	#27
2.7	Two Documents in a Stream	❌ deferred	#21
2.8	Play by Play Feed (multi-doc)	❌ deferred	#21
2.9	Single Document with Two Comments	✅ supported	—
2.10	Anchors and Aliases	❌ deferred	#22
2.11	Mapping between Sequences (? key)	❌ deferred	#25
2.12	Compact Nested Mapping	⚠️ verify	—
2.13	Literal block scalar	❌ deferred	#8
2.14	Folded block scalar	❌ deferred	#8
2.15	Folded — more-indented lines	❌ deferred	#8
2.16	Indentation determines scope	❌ deferred	#8
2.17	Quoted Scalars	✅ supported	—
2.18	Multi-line Flow Scalars	❌ deferred	#8
2.19	Integers (octal, hex)	❌ deferred	#26
2.20	Floating Point (.inf, .nan)	❌ deferred	#26
2.21	Miscellaneous	✅ supported	—
2.22	Timestamps	❌ deferred	#23
2.23	Various Explicit Tags	❌ deferred	#24
2.24	Global Tags	❌ deferred	#24
2.25	Unordered Sets (!!set)	❌ deferred	#24
2.26	Ordered Mappings (!!omap)	❌ deferred	#24
2.27	Invoice (full-length)	❌ deferred	depends on #22, #24, #8
2.28	Log File (multi-doc)	❌ deferred	depends on #21, #8

Acceptance criteria

• tests/Spec-1.2.2.Tests.ps1 exists and contains all 28 Chapter 2 examples
• Tests for ✅ rows pass without -Skip
• Tests for ❌ rows are present but -Skip-ped, each with a comment linking to the tracking issue
• README references the spec test file as the source of truth for coverage

[MariusStorhaug]

What changed: Reformatted the issue body to the MSXOrg Issue Format — a local Why plus an outcome-level What/acceptance criteria. Removed the Technical Decisions and Implementation Plan sections (and other implementation-tradeoff notes).
Why: Issue bodies should state local purpose and observable outcome without leaking implementation detail into the outcome-level description; durable technical decisions belong in the PR/design, not the tracking issue.
Follow-up: None.