fix(esx_drugs): track the processing bounds per player

[seltonmt012]

Description

outofbound is one variable shared by every player, so one person leaving the weed lab stops everyone else's processing.

---

Motivation

local outofbound = true

esx_drugs:outofbound is a net event, and its handler writes that single upvalue without looking at source. The processing loop reads the same one:

while outofbound == false and can do

So the first player who steps out of the lab ends the loop of every other player standing in it. Their cannabis stops turning into marijuana with no message and no way to tell why. Starting to process has the mirror problem: it sets the shared flag back to false, so one player walking in clears another player's out of bounds state.

There is a second effect on the same variable. esx:playerDropped calls CancelProcessing, which only removes the timeout id. The loop is still spinning, so on its next pass it finds no id and arms a fresh timeout against the xPlayer of somebody who already left the server.

---

Implementation Details

The flag is keyed by source, and CancelProcessing clears the entry so it does not outlive the session.

Clearing it also ends the loop of a dropped player, because the loop condition no longer holds. That falls out of the same change rather than being a separate mechanism.

Two players processing, both carrying enough cannabis that neither runs out, driven against the shipped handler on a fake scheduler:

scenario	before	after
nobody leaves (control)	2 of 2 loops alive	2 of 2 loops alive
player 2 walks out of the lab	2 → 0, player 1 dragged down	2 → 1
player 2 disconnects	2 → 2, the dead loop keeps arming timers	2 → 1

The control run is unchanged, which is what says the difference comes from the flag and not from the loop ending for some other reason.

---

Usage Example

-- two players processing in the lab, one of them walks out
-- before: both stop
-- after:  only the one who left stops

---

PR Checklist

• My commit messages and PR title follow the Conventional Commits standard.
• My changes have been tested locally and function as expected.
• My PR does not introduce any breaking changes.
• I have provided a clear explanation of what my PR does, including the reasoning behind the changes and any relevant context.

Scope note, so it is not a surprise later: the cancel path in this handler has problems this PR does not touch. esx_drugs:cancelProcessing is fired with TriggerEvent from inside the timeout, where source is not the player it means, and the loop re-arms a timeout whenever the map entry is gone. I kept this change to the shared flag because that is the part with cross player damage. Tell me if you want the rest folded in here instead of a follow up.

Tested headless against the shipped file, not with two clients on a live server.