Fix double chests double-counting their viewers

[KostiaFed]

Follow-up to #570, which fixed the same double count on the other path — that is why shulker boxes got better and chests did not.

Problem

The Bukkit-level viewer hooks on CompoundContainer called the vanilla startOpen/stopOpen, which drive ContainerOpenersCounter:

public void onOpen(CraftHumanEntity who) {
    this.container1.startOpen(who.getHandle());   // vanilla opener counter
    this.container2.startOpen(who.getHandle());

CraftBukkit calls container1.onOpen(who) there — transaction tracking only. ChestMenu's constructor already calls startOpen once, and CompoundContainer.startOpen fans that out to both halves, so every viewer of a large chest was counted twice. Single chests are unaffected: ChestBlockEntity's onOpen only adds to transaction, so the count stays balanced. Large chests are affected because CraftInventoryDoubleChest wraps the CompoundContainer.

Counted against 26.1.2 bytecode (ChestMenu ctor → one startOpen; removed → one stopOpen):

Step	Counter, per half
ChestMenu ctor → startOpen	0→1 — open sound, scheduleRecheck(+5 ticks)
transferTo → onOpen → startOpen	1→2
recheckOpeners five ticks later	one real viewer → corrects to 1, reschedules
close: transferTo → onClose → stopOpen	1→0 — close sound
close: ChestMenu.removed → stopOpen	0→−1, silently (decrementOpeners tests openCount == 0)
pending recheck	0 openers vs stored −1 → the actual == 0 branch → second close sound

Hence the erratic behaviour. Closed within five ticks, the sequence happens to balance (2→1→0) and everything is correct. Held open longer — nearly always — the counter ends at −1 and a second close sound arrives. While it sits negative, the next open never makes the 0→1 transition, so onOpen does not fire and no recheck is scheduled: the lid animation and the trapped-chest redstone output are left in the wrong state.

Changes

CompoundContainerMixin — onOpen/onClose delegate to the halves' ContainerBridge.onOpen/onClose, as CraftBukkit does. Each half still records the viewer in its own transaction (needed for per-half getViewers()), and only vanilla touches the opener count, so it moves exactly +1/−1.

ServerPlayerMixin — the InventoryOpenEvent cancel path leaked an opener per half on large chests. A large chest arrives as the anonymous MenuProvider that DoubleBlockCombiner builds, so neither factory instanceof Container nor factory instanceof CompoundContainer matched and the constructor's startOpen was never undone (+1 per half, lid stuck open). The CompoundContainer branch was unreachable regardless — CompoundContainer is a Container, so the first branch would have claimed it — and it only stopped container1. Now, when factory is not a Container, the container is taken from the ChestMenu that was created, and CompoundContainer.stopOpen fans out to both halves.

Scope and testing

gradlew compileJava passes. This is code and bytecode analysis, not an in-game test — worth verifying on a live server.

I found no counting asymmetry on the pure single-chest path: block click, player.openInventory, client close, server-side closeContainer(), and player disconnect all balance +1/−1. Reports of single chests misbehaving are most likely halves of large chests, or a half whose counter was already driven negative and stays broken after the pair is split.