test: assert ParamName in null-argument contract tests (#50)

[Chris-Wolfgang]

Summary

Strengthens the ArgumentNullException contract tests in the Wolfgang.Etl.TestKit.Xunit base classes so they assert the exact ParamName ("items" / "progress"), not just the exception type. Implements issue #50.

22 assertion sites updated across 9 files (extractor / loader / transformer × base + WithProgress + WithProgressAndCancellation):

• Sync (extractor/transformer): now capture var ex = Assert.Throws<…>(…) and assert ex.ParamName.
• Async (loader): Assert.NotNull(ex) replaced with Assert.Equal("…", ex.ParamName).

Why it's safe (zero blast radius)

The null checks live in the Abstractions base classes, which throw new ArgumentNullException(nameof(items)) / nameof(progress). Every downstream component built on those bases inherits this behavior, so the tightened assertion is satisfied by all shipping extractors/loaders/transformers without any downstream change.

Verification

• dotnet build -c Release — 0 warnings, 0 errors
• dotnet test -c Release (TestKit.Xunit consumer test project) — 195 passed, 0 failed

Scope note

This PR addresses #50 only. The companion contract-test issues #46 (CurrentItemCount increment ordering) and #49 (no upstream over-read) are not included — both need a maintainer decision first:

• Contract test: CurrentItemCount is incremented AFTER the item is yielded/loaded #46: its prose says increment after yield is correct, but its proposed assertion (count == i+1 after each MoveNext) and the actual TestExtractor implementation both use increment-before-yield. The spec is self-contradictory re: the intended ordering contract.
• Contract test: components stop mid-enumeration when MaximumItemCount / cancellation is hit (no over-read) #49: an extractor's upstream source isn't observable through the current contract base, so 'no over-read' can't be asserted without a new abstract hook (loader/transformer inputs are observable).

Closes #50

🤖 Generated with Claude Code