Fixed nametag text rendering off-screen with the custom font disabled

[c8dhjp4tyv-bit]

Type of change

• Bug fix
• New feature

Description

With Custom Font disabled, nametag text is drawn at the top-left of the screen (usually clipped off it entirely) instead of above the entity.

NametagUtils has two pairs of overloads:

public static void begin(Vector3d pos)                              // model-view stack only
public static void begin(Vector3d pos, GuiGraphicsExtractor graphics) // model-view stack + graphics.pose()

The graphics-less pair only pushes onto RenderSystem.getModelViewStack(). That is what CustomTextRenderer draws through (MeshBuilder / the UI_TEXT pipeline), so with the custom font everything lines up. VanillaTextRenderer.render() does not touch that stack at all — it draws through graphics.pose():

Matrix3x2fStack matrices = graphics.pose();
matrices.pushMatrix();
matrices.scale((float) scale, (float) scale);
graphics.text(mc.font, text, (int) (x / scale), (int) (y / scale), color.getPacked());

So at every call site using begin(pos), graphics.pose() was never translated to the entity's screen position and the text landed at its raw local offsets — which are negative (-widthHalf, -heightDown), hence off the top-left corner.

This is the same fix already applied to WaypointsModule in #6577 and to the player nametag path in Nametags#renderNametagPlayer; these call sites were just missed. All of them already had the GuiGraphicsExtractor in scope, so the change is passing it through:

Module	Affected text
Nametags	item, generic-living (mob), generic-entity and TNT nametags
EntityOwner	owner names
LogoutSpots	logged-out player name + health
CrystalAura	damage text
Notebot	note level / tune hits
HighwayBuilder	the P / N mining-mode letter

Player nametags were already correct, which is why the bug looks like "only some nametags are broken".

No behaviour changes with Custom Font enabled: begin(pos, graphics) calls begin(pos) internally, so the model-view path is untouched. The graphics-less overloads are kept (they are still used internally and are public API for addons).

Related issues

Closes #6593

How Has This Been Tested?

./gradlew compileJava passes.

I isolated the two transform paths and reproduced the offset numerically. Taking an entity projected by to2D to GUI-space (700, 300) and a mob nametag whose local offset is (-widthHalf, -heightDown) = (-25, -9):

custom font  (model-view path, works today) -> (675.0, 291.0)
vanilla font BEFORE fix (begin(pos))        -> (-25.0, -9.0)   <-- gui space
vanilla font AFTER  fix (begin(pos, gfx))   -> (337.5, 145.5)  <-- gui space
   ... x 2 gui scale = (675.0, 291.0)  == custom font result

position error before fix: (725.0, 309.0) px  (== the whole anchor offset)

Before the fix the text sits at negative coordinates — off the top-left of the screen, matching the screenshot in #6593. After it, the vanilla path lands on exactly the same pixel as the custom-font path.

In-game, with Custom Font off: item/mob/TNT nametags, EntityOwner, LogoutSpots, CrystalAura damage text, Notebot and HighwayBuilder's letter all now track their entity/block instead of piling up in the corner.

Checklist:

• My code follows the style guidelines of this project.
• I have added comments to my code in more complex areas.
• I have tested the code in both development and production environments.