threads corpus: remove racy create-basics completion oracle

Problem

reference/webkit-249/threads-tests/lifecycle/create-basics.js uses counters.spawned++ from eight concurrent workers as its completion oracle. The read/modify/write expression is not atomic, so a valid interleaving can lose an increment even though every thread ran and returned the correct result. CI run 29464204902 observed exactly that (expected 8, got 7).

The test already joins all workers and checks every lane's distinct return value, which is a stronger, race-free proof that all eight bodies completed.

Acceptance

• Remove the racy shared-property increment oracle from this lifecycle/constructor test.
• Keep the per-lane joinAll result checks.
• Re-run the focused case repeatedly and include it in the next corpus shard gate.

Fixed on main in e2384dcf: the redundant non-atomic shared-property increment is gone; all eight distinct joined results remain checked. The focused corpus case passed 50/50 consecutive runs. Keeping open until its full corpus shard is green.

Completed in e2384dcf. The focused case passed 50/50 locally and all four full threads-gil corpus shards were green in run 29465812082; joined per-lane results remain the race-free completion oracle.