Fix cooking sound, wilderness gates and walk clicks lost after opening doors

[HarleyGilpin]

Fixes #1129
Fixes #1126

Cooking sound (#1129)

Cooking on a range or fire never played a sound. Cooking.kt now plays the already-defined but unused cook sound (id 2577) once per item after the inventory swap, on both success and burn, matching 2009scape's playAudio(player, Sounds.FRY_2577) in CookingPulse.

Wilderness members fence gates (#1126)

The gate by the ice giants (and all six placements of gate pair 1596/1597 on the wilderness members fence) opened into objects 1562/1563, which are non-interactive placeholders in the cache with no name and no options, leaving an unclickable gate stuck in the fence.

• Mapped gate_29/30_opened (and the equally-affected gate_27/28_opened) to 1560/1561.
• Removed the suffixless gate_25/gate_26 duplicates of 1560/1561. They claimed the ids after gate_22/23_opened, so gates 1557/1558 answered Close with "The gate won't budge." Neither id has any static map placement.
• Added gate = false and material = "iron" consistently across every entry sharing these ids (definition params are last-write-wins per int id), so the whole family opens as a plain double door with the iron door sounds (71/70), matching 2009scape's metal gate audio.

Extra input delay after opening doors/gates

Opening any door then clicking to walk through did nothing until a second or two later, even after the door was visibly open. ObjectTeleporting registers an operate handler for every teleport option, including "Open", and its block called delay() before checking whether the target actually has a teleport, so every door and gate open ran a second unconditional 1 tick input lock after the door script finished. The handler now looks up the teleport definition first (using the player-aware transformed object id, since some teleport objects are varbit transformed) and returns early when there is none.

Tests

New WildernessGateTest opens the actual Ice Plateau gate from the map, walks through, and closes it. Full :game:test suite passes.

[GregHib]

Opening any door then immediately clicking to walk through did nothing until the player clicked again a second or two later. Object interactions set a 1-tick arrive delay before their script runs, and the Walk instruction handler silently discarded clicks while delay was set, instructions process before the delay counts down, so every click in the ~2 ticks after opening was lost with no feedback.

Walk clicks received during a delay are now buffered as a weak-queued action: the latest click executes on the exact tick the delay expires (the same tick the door finishes opening). Newer clicks, new interactions and strong queues (cutscenes, random events) still discard the pending walk, and long locks like agility obstacles or teleports keep gating input until they end.

Not sure this is correct, I think instead the issue is the arriveDelay isn't functioning properly, if you're next to a gate and click it then click to walk - there should be no arrive delay triggered. If you're more than 1 tile away from the gate then the gate interaction should be cancelled

[HarleyGilpin]

Tracked down the lingering tick: it wasn't arriveDelay at all. ObjectTeleporting registers an operate handler for every teleport option, including "Open", and its block called delay() before checking whether the object actually has a teleport. So every door and gate open ran a second unconditional 1 tick delay after the door script finished, which is why clicks were still being eaten a full tick after the gate was visibly open.

Fixed in d161437: look up the teleport definition first (using the player-aware transformed id, since some teleport objects are varbit transformed) and return early when there is none. With that, the input lock now clears on the same tick the door opens, and the only remaining window is the single legitimate arrive delay tick.