Fixed the armor hud crashing when durability text is enabled

[c8dhjp4tyv-bit]

Type of change

• Bug fix
• New feature

Description

Setting the armor hud's Durability to Total or Percentage crashes the game as soon as the element is drawn:

java.lang.RuntimeException: VanillaTextRenderer.render() called without calling begin()
	at meteordevelopment.meteorclient.renderer.text.CustomTextRenderer.render(CustomTextRenderer.java:93)
	at meteordevelopment.meteorclient.systems.hud.elements.ArmorHud.lambda$render$0(ArmorHud.java:186)
	at meteordevelopment.meteorclient.systems.hud.HudRenderer.end(HudRenderer.java:108)

ArmorHud draws its items from a renderer.post(...) task, and the durability text inside that task was drawn with the global TextRenderer.get() without ever beginning it. Post tasks are the last thing HudRenderer.end() does, after the text batch for the frame has already been flushed:

public void end() {
    Renderer2D.COLOR.render();

    if (hud.hasCustomFont()) {
        ... // flush the font meshes
    } else {
        VanillaTextRenderer.INSTANCE.end();
    }

    for (Runnable task : postTasks) task.run();   // <- ArmorHud draws here

so by the time the task runs, neither text renderer is building and render() throws. This affects both fonts — CustomTextRenderer throws the same (copy-pasted) message, which is why the report's crash log points at CustomTextRenderer.

The fix is the pattern CombatHud already uses for the text it draws inside its own post task: begin the renderer around the text and end it afterwards. It is begun once for all four slots rather than per slot, and only when durability text is actually enabled, so there is one extra text batch per frame at most. The renderer is resolved into a local so that the begin, the measurements, the render and the end all go through the same instance.

Since the text is now measured and drawn by the same renderer, the layout calls were moved over to it as well (TextRenderer.get().getWidth/getHeight instead of renderer.textWidth/textHeight). renderer.textWidth() measures with HudRenderer's own font atlas, which is not the font TextRenderer.get() draws with, so the old code could not centre the number reliably even when it happened not to crash. The measurements are now also shadow-aware, matching the durability-shadow setting used when rendering.

The itemStack.isDamageableItem() && durability.get() != ... condition was hoisted into the durabilityText local; it is loop-invariant apart from the per-stack check.

Related issues

Closes #6576

How Has This Been Tested?

./gradlew compileJava passes.

The crash is deterministic and reproduces from the report's steps on both font settings: add the armor hud, set Durability to Percentage (or Total) and leave the hud editor. Before the change the client crashes on the first frame the element is drawn; after it the durability numbers render centred under each armor piece, with Custom Font both on and off, in Horizontal and Vertical orientation.

I also checked the other hud elements that draw from a post task — ItemHud, InventoryHud, HoleHud, MapHud, PlayerModelHud draw no text there, and CombatHud already begins/ends its renderers itself — so ArmorHud was the only affected call site.

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.