Keep jobs of attuned interfaces in the network when their target updates

[rubensworks]

Targets such as furnaces notify their neighbours whenever their contents change, so on every inserted input and every extracted output. PartTypeInterfaceCraftingAttuned.onBlockNeighborChange reacted to each of these by unregistering the interface from the crafting network (removeTargetFromNetwork). It only registered again on the interface's next part update (addTargetToNetwork only sets shouldAddToCraftingNetwork).

In between, which was 20 to 40 ticks in a test world, the interface's crafting jobs were missing from the network's dependency graph:

• Jobs that depend on them had no dependencies left, so they were reported as PENDING_INGREDIENTS with their stale missing ingredients. In Integrated Terminals, this shows the plan of a running job briefly failing with missing ingredients after every smelted item.
• Each re-registration also added the dependency edges of the interface's jobs again, which caused the duplicate edges fixed in Fix duplicate crafting job dependencies when interfaces re-register #248.

Attuned interfaces now only re-register when their target gained or lost its recipe handler, or exposes other recipes than the ones that were last read.

Testing:

• New game test testAttunedTargetUpdatesKeepJobDependencies: attuned interfaces on a crafting table and a furnace craft a stone button from cobblestone. Every tick while the furnace is smelting, it checks that the smelting job stays in the dependency graph and that the button job keeps waiting for it. It fails without the fix ("The smelting job left the dependency graph").
• ./gradlew build and all 81 game tests pass.
• Reproduced in a dev client on a world with attuned interfaces on a furnace and a crafting table, while crafting 4 furnace minecarts. Before: after every smelted iron ingot, the iron job left the graph for 20 to 40 ticks, and the minecart job switched to PENDING_INGREDIENTS. After: in the same world and job, this never happened over 12 ingots, and the job completed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C5iUzweRYoCkKB5bvJdH8Y

---

Generated by Claude Code

[rubensworks]

coverage/coveralls reported a 0.2% coverage drop from the first of the two Build runs on this commit. That Build run itself passed, including unit tests and game tests.

The drop doesn't come from code this PR removes. The only new main code is hasTargetChanged(), which the new game test runs on every furnace update. Its only uncovered line is the getTarget() == null guard. I expect the rest is run-to-run variance in game test coverage: on #248, the first run also reported a decrease (-0.09%), and the second run on the same commit reported an increase (+0.2%). The second Build run here is still in progress.

---

Generated by Claude Code