Calendar validation for assembled EDTF structs.

EDTF.Parser only checks structure (digit counts and separators), so an impossible value like "1999-02-30" or a bad season code matches the shape and parses. valid?/1 walks an assembled tree and rejects dates that can't denote a real calendar date.

Unspecified digits (X)

A component is validated only when it is fully concrete. A component that contains any unspecified digit is treated as a wildcard and trusted, since the author explicitly marked it unknown — e.g. 1999-02-3X is accepted even though no day 30–39 exists in February, because the day's units digit is unknown.

But a fully concrete component is always checked, even when a neighbouring component is unspecified: 1999-13-XX and XXXX-13-01 are rejected (month 13 is concrete and impossible), and 19XX-02-30 is rejected (day 30 can't fall in February). When the year is unspecified we can't know whether it is a leap year, so February is allowed up to day 29 (19XX-02-29 is accepted).

Qualifiers (?, ~, %) don't change the value, so they are always validated. Validation leans on the standard library's proleptic-Gregorian calendar, matching how EDTF.DateRange resolves dates.