Format UTC offsets with the invariant culture

[SimonCropp]

GetDateOffset in src/Verify/Serialization/DateFormatter_DateTimeOffset.cs built the offset with plain interpolation, so the numbers went through CurrentCulture, while every other part of the rendered date in that file passes Culture.InvariantCulture explicitly.

NumberFormatInfo.NegativeSign is not - everywhere:

Culture	Negative sign	-01:30 renders as
invariant / en-US	U+002D	-1-30
sv-SE	U+2212	−1−30
ar-SA	U+061C U+002D	؜-1؜-30
fa-IR	U+200E U+2212	‎−1‎−30

Only negative offsets are affected; the positive and zero branches write a literal +.

Impact

The string reaches two places.

• Snapshot content, via DateFormatter.Convert. A DateTimeOffset serialized on a Swedish machine differs from the one committed from an en-US machine even though the values are equal.
• Parameter file names, via DateFormatter.ToParameterString. The verified file for a parameter with offset -05:00 is looked up under a name that machine can never produce a match for, so the test reports the snapshot as new on every run.

Change

The four interpolations now go through FormattableString.Invariant, which keeps the format strings in place and is available on every target framework down to net462. Output under the invariant culture is byte identical, so no existing snapshot moves.

Test

DateFormatterTests.OffsetDoesNotTakeTheCurrentCultureNegativeSign pins all five branches (-1.5, -5, +1.5, +5, 0) against expected literals while CurrentCulture carries U+2212 as its negative sign. The sign is assigned onto a clone of the invariant culture rather than picking a real culture, so the assertion does not move with the ICU data the test runs against.

Confirmed the test fails on unpatched source (both negative cases, positives unaffected) and passes after. Full Verify.Tests suite green: 1304 passed, 0 failed. Verify.csproj builds clean across all nine target frameworks.