Problem

Closes #3602.

startTransitionScript checks the expected executionID by decoding the full
sandbox JSON blob with cjson.decode. Because Redis executes all Lua on a
single-threaded event loop, this O(N) decode blocks every other Redis command
for its duration. Under production load (thousands of concurrent sandboxes) this
creates measurable latency spikes on all storage operations.

Solution

Introduce a dedicated execution-ID key per sandbox:

sandbox:storage:{teamID}:sandboxes:{sandboxID}:eid

The key uses the same {teamID} hash tag as the main sandbox key, so it lands
in the same cluster slot and can be accessed atomically within Lua scripts.

Changes

Hot path before vs after

Before — every StartRemoving call with ExpectExecutionID set:

local current = redis.call('GET', KEYS[1])  -- fetch full JSON blob
local decoded = cjson.decode(current)        -- O(N) parse, blocks event loop
if decoded['executionID'] ~= ARGV[5] then return 0 end

After — O(1) string compare:

local eid = redis.call('GET', KEYS[4])  -- tiny string key
if eid ~= ARGV[5] then return 0 end

Migration safety

The eid key does not exist for sandboxes created before this deploy. The script
detects this case and falls back to cjson.decode so pre-deploy sandboxes
continue to work correctly. The fallback becomes unreachable once all pre-deploy
sandboxes have expired and can be removed in a follow-up cleanup.

Test plan

• Unit: verify addSandboxScript sets eid key with correct value
• Unit: verify removeSandboxScript deletes eid key
• Unit: verify startTransitionScript returns 0 on executionID mismatch (fast path)
• Unit: verify startTransitionScript falls back correctly when eid key absent (migration path)
• Integration: sandbox lifecycle (create → start removing → remove) completes without error
• Load: confirm reduced Redis command latency under concurrent sandbox operations