[1.21]Stale EntityIota read from iota holders can cause NPE and client disconnect

[tozyx]

Modloader

NeoForge

Minecraft version

1.21.1

Hex Casting version

1.21 branch build

Modloader version

NeoforgeVersion:21.1.220

Modpack info

No response

The latest.log file

https://mclo.gs/AeIvi4A

Issue description

When an EntityIota is stored in an iota holder, such as a spellbook, thought-knot, or similar readable item, and the referenced entity no longer exists, reading the stored iota can still return the old entity iota for one evaluation step.

For example, if the entity has died, unloaded, or the referenced player is offline, using Scribe's Reflection / iota read on the holder still appears to read the old entity. The stack only updates to Null after the next pattern is drawn or evaluated.

This becomes more serious when the read happens during list evaluation. If the list reads an entity iota from the offhand item and then immediately uses it as an entity argument, the stale EntityIota can reach entity-consuming patterns before it is validated.

In a minimal development client, this may only produce an internal exception and make the spell fail. In a modpack environment, the same exception can additionally cause a clientbound/minecraft:system_chat encoding failure and disconnect the client.

Expected behavior: reading an iota holder should immediately normalize invalid entity iotas to NullIota. The client should not be disconnected by the mishap/error message.

Possibly related to #1097 and #1062, but this report is specifically about stale EntityIota values read from iota holders not being validated immediately, which can lead to an internal exception and a system chat packet encoding disconnect.

Steps to reproduce

1. Store an entity iota in a spellbook, thought-knot, or another readable iota holder.
2. Make the referenced entity unavailable, for example by killing it, unloading it, or having the referenced player go offline.
3. Read the stored iota using Scribe's Reflection / iota read.
4. Observe that the old entity iota is still returned instead of Null.
5. Draw or evaluate another pattern.
6. Observe that the stack only updates to Null after the next validation step.
7. Optional: put the read operation inside a list evaluation and immediately use the result as an entity argument, such as with Blink.
8. Observe an internal exception. In some modpack environments this can also disconnect the client due to a system_chat packet encoding failure.

Other information

No response

[tozyx]

I opened a PR with a possible fix: #1161

The PR validates iotas read from holders immediately, handles missing entities as MishapEntityNotFound, and avoids passing raw exception objects into translated chat components.