fix: reject unknown IANA time zones in Instant::toString()

[ethanhawkes-gif]

Fixes #60.

Problem

validateTimeZoneString() only checks syntax, so a well-formed but unrecognized IANA identifier passes it and reaches the offset lookup, where it is silently rendered as UTC — while toZonedDateTimeISO() correctly throws a RangeError for the same input. The two entry points disagreed.

Instant::fromEpochMilliseconds(0)->toString(['timeZone' => 'Bogus/Zone']);
// before: "1970-01-01T00:00:00+00:00"   (silent UTC)

Instant::fromEpochMilliseconds(0)->toString(['timeZone' => '1970-01-01T00:00+01:00[Bogus/Zone]']);
// before: "1970-01-01T01:00:00+01:00"   (bogus bracket swallowed, inline offset used)

Per TC39 (ToTemporalTimeZoneIdentifier / GetAvailableNamedTimeZoneIdentifier), an unknown time zone identifier is a RangeError.

Fix

Two toString()-path swallow sites now throw instead, matching toZonedDateTimeISO():

• ianaOffsetSeconds() — a bare unknown IANA name previously fell back to offset 0 (→ UTC).
• resolveTimeZoneOffsetSeconds() — an unknown bracket zone previously fell through to the inline offset.

Both helpers are private with a single caller each, only in the toString() path.

Tests

Adds Porcelain regression tests for both unknown-zone paths plus positive coverage for valid bare and bracketed IANA zones. Local verification:

• Full suite: 12,400 tests pass (+4 new, 0 regressions).
• PHPStan level 9, Psalm level 1, Mago lint + analyze, and Mago format-check all clean (zero new issues).

🤖 Generated with Claude Code