HUD time display ({time} / server time) uses gameTime (world age) instead of World Clock on 26.1+

[Promptt001]

Describe the bug

On Minecraft 26.1 and later, the time displayed by the HUD {time} Starscript variable (e.g. the Info HUD "Server time" line) does not match the actual day/night cycle.

Root cause: Minecraft 26.1 moved the day/night cycle to data-driven World Clocks; /time and time-of-day now operate on those clocks, while Level#getGameTime() is the world/simulation age and is explicitly unaffected by /time changes (per the 26.1 release notes, time query gametime is independent of World Clock changes).

Utils#getWorldTime() in src/main/java/meteordevelopment/meteorclient/utils/Utils.java still formats the world-age counter as time of day:

int ticks = (int) (mc.level.getGameTime() % 24000);

The result looks like a clock but is actually world age mod 24000, which only matches real time of day by coincidence.

Suggested fix — read the dimension's default World Clock (the same clock /time targets when no explicit clock is given):

long ticks = Math.floorMod(mc.level.getDefaultClockTime(), 24000L);
ticks = (ticks + 6000L) % 24000L;

I've implemented and tested this in a fork (commit 45740ad: Promptt001@45740ad) and opened PR #6666 with the change.

Steps to reproduce

1. Join a 26.1+ server (tested on Paper 26.2 build Added Skylight Updates to NoRender #123) with Meteor 26.2 Move to brigadier for commands #23.
2. Display the HUD time (Info HUD "Server time" / {time}).
3. Have an operator run /time set day (or /time set night).
4. The sky, clock items in item frames, and daylight detectors all update immediately — the Meteor HUD time does not change and keeps ticking on its own independent cycle.
5. All Meteor users on the server observe the same wrong value; comparing with /time query gametime shows the HUD is tracking world age, not the world clock.

Meteor Version

Meteor 26.2 #23

Minecraft Version

MC 26.2

Operating System

Linux

Before submitting a bug report

• This bug wasn't already reported (I have searched bug reports on GitHub).
• This is a valid bug (I am able to reproduce this on the latest dev build).