fix(ace): gate ACE explosives placement on locality

[fank]

Summary

• ACE-placed explosives have been recorded at the map origin (0,0,0) on dedicated servers.
• Root cause: ace_explosives_place is a CBA global event, so the listener body ran on every machine. On a dedicated server the explosive's position is not yet network-synced when the event fires — getPosASL returns 0,0,~0. The placer's client has the correct position immediately.
• Fix: gate execution on local _explosive so only the placer (which owns the object with the authoritative position) packages the data and forwards it via CBA_fnc_serverEvent. Same pattern as the vanilla mine path in fnc_eh_fired_client.sqf.

Test plan

• Dedicated server: place an ACE explosive, confirm :PLACED:CREATE: arrives with the real position (not 0,0,...).
• Hosted/SP: place an ACE explosive, confirm recording still captures it.
• Detonate/delete an existing ACE charge, confirm :PLACED:EVENT: detonated/deleted still fires (lifecycle EHs are added on the placer's machine, same machine that already ran them before this change).

[gemini-code-assist]

Code Review

This pull request introduces a locality check in fnc_aceExplosives.sqf to ensure that only the machine where an explosive is local processes the placement event, preventing incorrect position data (0,0,0) on dedicated servers. The reviewer noted that gating the entire function prevents lifecycle event handlers from being registered on other machines, which could lead to lost tracking if the object's locality changes (e.g., due to a player disconnect). It is recommended to restrict the locality check to the data transmission logic while allowing event handler registration to proceed globally.

[fank]

Addressed in ba2e734 — moved the locality check to gate only the :PLACED:CREATE: data send. The HitExplosion/Explode/Deleted EHs now register on every machine, so whichever machine owns the explosive at event-time fires its local EH. Order of operations: EHs registered first → server processes handlePlacedData and broadcasts the placedId via public setVariable → lifecycle EHs find it when they fire.

[fank]

Reworked in 327d7ca. The locality fix was wrong — the log showed no :PLACED:CREATE: arrived at all, but the Deleted event came through with a valid frame number, which only the server has (OCAP_recorder_captureFrameNo is set by the server-only captureLoop). So local _explosive is true on the server, not the placer — and a client send wouldn't have worked anyway because captureFrameNo is nil there.

New approach: send from the server with a 1s CBA_fnc_waitAndExecute delay, matching the empirical timing ("server after delaying 1 second shows coords correctly"). EH registration stays on every machine for locality-transfer resilience.

Caveat to flag: there's now a 1s window between placement and the :PLACED:CREATE: send. If a charge detonates within that window (rare for satchels, possible for tripwires/IEDs), the lifecycle EH will fire with placedId = -1 since the server hasn't assigned it yet. The previous code had the same race in theory; with the delay it's now a guaranteed minimum window. If that becomes an issue we can buffer lifecycle events until placedId is assigned, but I'd treat that as a follow-up.

[fank]

Correction: you're right, captureFrameNo is publicVariabled (fnc_captureLoop.sqf:60, fnc_init.sqf:49, fnc_exportData.sqf:162) and clients use it directly in the vanilla fired-client paths. My earlier rationale for why the locality-on-placer fix produced no :PLACED:CREATE: was wrong.

What we actually know empirically: with if (!local _explosive) exitWith {}; no send arrived. We don't actually have proof of where locality was true — frame=64 on the Deleted event doesn't pin it down.

The server-only + 1s delay fix still stands on the simpler grounds you originally flagged: getPosASL on the server needs ~1s to reflect the settled position. Cleaned up the misleading comment in 0c9eeb9.