fix(bulk-operations): chunk CS Assets bulk delete/move to the 100-item API cap (DX-9732)

[naman-contentstack]

Problem

DX-9732: cm:stacks:bulk-assets --operation delete fails with HTTP 422 when the asset-uids file has >100 entries:

CS Assets API POST failed: status 422 ... {"errors":["Assets cannot exceed the max limit of 100."],"error_code":422}

The adapter sent the entire asset array in one POST. The CS Assets bulk delete/move endpoints cap each request at 100 items, so any bulk delete over 100 assets was completely blocked with no CLI workaround. bulkMoveAssets had the same shape.

Fix

Chunk to the cap and dispatch the batches — the publish-side QueueManager was the wrong tool (SDK/CMS-auth coupled; the delete path deliberately skips that pipeline), so this reuses the asset-management adapter's own concurrency primitives.

• Chunking (adapter). CSAssetsAdapter.bulkDeleteAssets/bulkMoveAssets split the payload into ≤100-item batches (CS_ASSETS_BULK_MUTATE_MAX_ITEMS) via a shared dispatchBulkMutateBatches, dispatched with bounded concurrency (makeConcurrentCall) and per-batch retry (postJson({retry:true}) — 429/5xx retried, 4xx like the 422 cap not).
• Continue on partial failure. Failed batches are collected, not rethrown (each request commits independently server-side). The aggregate result carries job_ids, notices, batchesTotal, batchesSucceeded, and failures[] ({batchIndex, count, status, error, uids}).
• Typed errors. postJson throws CsAssetsPostError carrying the HTTP status — no error-string parsing.
• Partial-failure UX. The runner reports what committed vs failed, writes the failed uids to a {"uids":[...]} file in the bulk-operation log folder, and prints a re-run hint (--asset-uids-file). No --retry-failed (CMS-only). Delete messaging states a submitted job is submission, not completion (delete is async).

Testing

• contentstack-asset-management: 245 passing — adapter chunking (250→3 batches ≤100), partial-failure aggregation, failed-uid capture.
• contentstack-bulk-operations: 831 passing — service aggregate mapping, runner partial-failure file write.
• Verified end-to-end against a 628-uid file: 7 batches of ≤100, no 422.

🤖 Generated with Claude Code

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	18	200	25	✅ Passed
🟡 Medium Severity	2	2	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

⚠️ Warning: The following vulnerabilities have exceeded their SLA thresholds (days since publication).

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	1	90 / 365 days	⚠️ Warning
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 200
• Medium without fixes: 2
• Low without fixes: 0

⚠️ BUILD PASSED WITH WARNINGS - SLA breaches detected for issues without available fixes

Consider reviewing these vulnerabilities when fixes become available.