Honor EoTime timezone assignments

[OskarEichler]

Summary

EoTime#zone= currently ignores its argument and resolves the existing zone instead. Use the supplied zone, reject an unresolvable zone before mutating the object, and retain existing cache invalidation.

Nil continues to preserve the current zone; :local resolves the local zone explicitly.

Reproduction

time = EtOrbi::EoTime.new(0, "UTC")
time.hour # populate the cached local time
time.zone = "Asia/Kolkata"
[time.zone.name, time.hour, time.min, time.to_f]

Before: ["UTC", 0, 0, 0.0]. After: ["Asia/Kolkata", 5, 30, 0.0].

Also checked TZInfo object assignment, :local, nil, preservation of the absolute instant and rejecting "Invalid/Timezone" without corrupting the previous valid zone.

Verification

• Ruby 4.0.6 via rbenv; existing Probatio suite, no test files added or modified.
• Reviewed master baseline and this individual patch each run 270 tests / 412 assertions with exactly the same three pre-existing DST/rday failures from rday / rweek calculation is odd in time zones with DST #51. Failure identities were compared, not just counts.
• A release-based 1.4.1 branch containing the five separately proposed fixes passes 263 existing tests / 405 assertions with TZInfo 2.0.6 in UTC, Asia/Tokyo, America/Chicago, Europe/Istanbul and the detected local zone.
• Temporary focused before/after reproductions pass with TZInfo 2.0.6 and 1.2.11. The combined release branch also passes the existing TZInfo 1.2.11 suite at seed 36231. Seed 99751 has the same pre-existing Zulu test-order failure on both unmodified release and patched release: a test mutates the cached TZInfo object's comparison method.
• Ruby syntax and gem packaging checks pass. Targeted Lint passes on the combined branch with the existing, unrelated AssignmentInCondition warning excluded; no lint configuration was changed.

The current master's unreleased day-delta change was not brought into the consumer branch. No live scheduler or production operations were used. Linux/Windows and other Ruby runtimes were not run locally.

Breaking changes and limitations

Valid assignments now take effect instead of silently doing nothing. Invalid zone assignments now raise ArgumentError immediately, leaving the previous zone intact; callers relying on silently ignored assignments will observe this correction. No other time conversion or DST policy changes. No overlapping open PR or assignment issue was found.