AHLIYA SMP RTP QUEUE - TEST V1 FIXED9

TO QUEUE: just type
  /trigger rtpq
No "set 1" needed - a bare /trigger <objective> in vanilla Minecraft
defaults to adding 1 to the score, and this pack watches for any
score of 1 or higher, so plain /trigger rtpq works on its own.

CHANGE IN THIS VERSION (FIXED9):

Dropped FTB Essentials' /rtp entirely - it doesn't take a distance
argument, it just uses whatever min/max radius is set in its own
config file, which is why the last test landed both players just
under spawn instead of far away.

Now the pack rolls its own random destination using vanilla's
/random value command: X and Z are each independently rolled to
3000-3500 blocks in a random direction (+ or -), which guarantees
the real distance from spawn (0,0) is always AT LEAST ~4243 blocks
(worst case, both roll the same diagonal) - comfortably past 3000.
Those coordinates are handed to a small macro function
(spread_at.mcfunction) that runs vanilla /spreadplayers pinned to
that exact spot (spreadDistance 0, maxRange 2) purely to reuse its
safe-ground search - it finds solid, non-lava/non-water surface
under y=200, so you land on actual ground instead of getting
dropped mid-air or buried in a cave ceiling. The second queuer is
then still brought to the first queuer's landing spot, 8 blocks
away, same as before.

Added sound effects: a "challenge complete" chime plays for both
players the moment a match is found, and a wither-spawn roar plays
right as the fight titles appear (after teleporting).

CHANGE IN FIXED8:

FIXED7's try_match.mcfunction called a helper function (tag_partner)
to tag the found partner, and used `execute store success ... run
function ...` to check whether that worked. That's broken as of
Minecraft 1.20.2: .mcfunction files are "void" by default (no return
value) unless they explicitly use /return, so store success had
nothing to read back from a plain function call - it silently stored
nothing, #found stayed 0 forever, and the match was undone every
single time. That's why queuing never matched anyone, even with two
players waiting.

Rewritten to avoid `execute store` on a function entirely:
try_match.mcfunction now tags the found partner with a unique
rtpq_first marker directly (no helper function), checks for success
with `if entity` instead of a stored score, and only THEN safely
tags that same uniquely-marked player rtpq_match.

CHANGE IN FIXED6:

Previously, start_match.mcfunction ran spreadplayers on BOTH matched
players at once. spreadplayers finds a safe location independently
for each target and only guarantees they land somewhere within the
overall radius of each other's search - not right next to each
other - so the two players could (and did) end up teleported to
completely different spots on the map instead of 8 blocks apart.

Fixed by giving the two matched players different roles:
- The FIRST player (the one who was already waiting) is the only one
  who gets a real random teleport.
- The SECOND player (the one whose /trigger completed the match) is
  then teleported directly TO the first player's new position, offset
  8 blocks on the X axis (and 1 block up, so they don't spawn inside
  a block).

This required tracking which of the two matched players was "first".
A new tag_partner.mcfunction and an rtpq_first tag were added so the
already-waiting player can be tagged rtpq_match AND rtpq_first in a
single execute...as call (doing that as two separate selector queries
risked tagging two different players if a 3rd person was also
waiting). load.mcfunction's reload safety net now also clears
rtpq_first.

Two real bugs were fixed in earlier versions (from V1 FIXED2):

1. join.mcfunction / try_match.mcfunction were using
   `execute if entity @a[tag=...,limit=2]` to try to check "are there
   2 waiting players?". In vanilla, `limit` only caps the MAXIMUM
   number of entities a selector returns - it does not enforce a
   MINIMUM. `if entity` just checks "found at least 1", so with only
   ONE player queued, this check was already true. That's why a
   single player would instantly "self-match" against nobody.
   Fixed by using `execute store success score ...` when trying to
   tag a second (different) player.

2. start_match.mcfunction (now removed) used:
     spreadplayers 0 0 8 10000 under motion_blocking true @a[tag=rtpq_match]
   `under` in /spreadplayers expects a Y-level NUMBER (e.g. `under 100`),
   not the word "motion_blocking". This made the command fail silently
   every time, so nobody ever actually got teleported.

IMPORTANT: Still a SAFE TEST BUILD. Only tests queue + RTP for 2
players. Does NOT implement death/winner/loot yet.

Install under world/datapacks/, then run /reload (or restart) and
check /datapack list.

TO TEST:
1. Account A: /trigger rtpq  -> "You are now waiting for an opponent."
   (nothing else should happen - no self-match, no teleport)
2. Account B: /trigger rtpq  -> both accounts get "MATCH FOUND!" + a
   chime sound, then a few moments later:
   - Account A (the first to queue) gets teleported 3000+ blocks from
     spawn in a random direction, landing on solid ground
   - Account B lands right next to A, 8 blocks away
   - Both hear a roar and see "THE FIGHT HAS BEGUN"

