Bulk-scan inventory loading has no input-size or repository-count limit

[GautamSharma99]

Summary

Bulk scan materializes inventories without resource ceilings:

• CSV loading in runMultiscan
• full Papa Parse materialization
• GitHub repository accumulation

A supplied CSV is read completely into a UTF-8 string, parsed into a complete row array, and then mapped into another task array. There is no maximum file size, row count, or campaign repository count.

Interactive discovery similarly accumulates every qualifying repository before selection and inventory creation.

Why this matters

An accidentally huge or adversarial CSV can cause excessive memory use before any checkout begins. A very large organization can produce the same behavior through discovery. It can also create a campaign whose checkout, scan, and model-cost scope is much larger than the user expects.

Per-field validation does not bound the number of fields or rows and therefore does not address aggregate resource use.

Expected behavior

Bulk scan should reject an inventory that exceeds documented byte and repository-count ceilings before campaign state or checkouts are created.

Suggested direction

• Check CSV metadata against a maximum byte size before reading.
• Enforce a maximum repository/task count during parsing and GitHub discovery.
• Prefer incremental CSV parsing to avoid retaining the source string and every parser row simultaneously.
• Stop GitHub pagination with an actionable error once the campaign limit is reached.
• Document the limits and add boundary/overflow tests.

Existing tests cover CSV correctness and repository pagination but not oversized inputs or excessive task counts.

Found by static audit of upstream main at 9c7634b.