Bound concurrent filesystem reads

[CR29-22-2805]

Closes #278

💸 TL;DR

Bounds concurrent filesystem reads during CLI asset collection and source ZIP generation.

Large projects previously started a filesystem read for every discovered file at once. This change limits those reads to 16 concurrent operations, reducing the risk of excessive memory usage or file-descriptor exhaustion.

📜 Details

This PR applies the existing mapAsyncWithMaxConcurrency() utility to two CLI filesystem operations:

• queryAssets() now limits concurrent asset reads to 16.
• getAppSourceZip() now defers source-file reads and processes them with a concurrency limit of 16.

Directory traversal behavior remains unchanged. The source ZIP function continues to process directories serially after completing the bounded file reads for the current directory.

No public API behavior is changed.

Design Doc: N/A

Jira: N/A

🧪 Testing Steps / Validation

• Ran git diff --check successfully.
• Reviewed the complete staged diff for both modified files.
• Confirmed the unbounded asset-read Promise.all() was replaced with mapAsyncWithMaxConcurrency().
• Confirmed source-file reads are deferred rather than started while directory entries are collected.
• Confirmed the source ZIP operation no longer calls Promise.all(filePromises).

A complete local dependency installation and test run could not be performed because the public repository references unpublished internal packages, including devvit@0.13.9-dev and @reddit/faceplate-ui.

✅ Checks

• CI tests (if present) are passing
• Adheres to code style for repo
• Contributor License Agreement (CLA) completed if not a Reddit employee