Fix JS upload worker shutdown

[TorstenDittmann]

What

• Stop Node and React Native upload worker loops from dispatching new chunks after a chunk upload fails
• Stop Web/Console upload scheduling after the first rejected chunk

Why

Greptile flagged that concurrent workers could keep draining queued chunks after the caller had already received a failure, causing extra background requests and possible progress callbacks after rejection.

Verification

• composer lint-twig
• git diff --check
• composer test tests/Node18Test.php
• composer test tests/WebChromiumTest.php
• composer test tests/ReactNativeTest.php
• composer test tests/CLIBun13Test.php

[greptile-apps]

Greptile Summary

This PR fixes a bug where concurrent upload workers continued dispatching new chunks after an initial chunk failure, causing spurious background requests and post-rejection progress callbacks. The fix is applied consistently across the Node, React Native, and Web/Console SDK templates.

• Node & React Native: Introduces a shared failed boolean flag into each worker-pool loop. Workers check !failed before dequeuing the next chunk, and a try/catch block sets the flag and re-throws on failure so Promise.all correctly propagates the error.
• Web/Console: Adds a rejected flag checked at the top of the uploadNext() scheduler function, and replaces .catch(reject) with an explicit handler that sets rejected = true before calling reject(error), preventing any further scheduling even while other uploads are still in-flight.

Confidence Score: 4/5

Safe to merge — the changes are small, targeted, and do not alter the happy-path upload flow.

The logic is correct in all three templates. The failed/rejected flags are properly placed before chunk dequeue/schedule decisions, and re-throwing in the Node/React-Native workers ensures Promise.all propagates the error as expected. In the web template, the rejected guard is ordered before the completed === chunks.length check, so resolve() can never be called after rejection. The only residual behaviour worth noting is that inFlight is not decremented in the web .catch() handler — but this was already true in the original code and has no observable effect once the outer promise is settled.

No files require special attention, though verifying the generated SDK output via composer test against all three templates is worthwhile given the templates produce the actual shipped code.

Important Files Changed

Filename	Overview
templates/node/src/client.ts.twig	Adds a shared failed flag to both worker-pool upload loops so workers stop dequeuing new chunks once any chunk fails; error is re-thrown so Promise.all propagates it correctly.
templates/react-native/src/services/template.ts.twig	Identical worker-pool fix to the Node template — adds failed flag with the same try/catch/re-throw pattern.
templates/web/src/client.ts.twig	Adds a rejected flag to the scheduler-based upload loop; uploadNext() returns early once set, and the .catch() handler now sets the flag before calling reject() instead of passing reject directly.

_{Reviews (1): Last reviewed commit: "Stop JS upload workers after chunk failu..." | Re-trigger Greptile}