sf project generate manifest --from-org silently drops metadata types unless SF_LIST_METADATA_BATCH_SIZE is set #3670

Summary

sf project generate manifest --from-org still drops whole metadata types at random and reports success, unless SF_LIST_METADATA_BATCH_SIZE is set. That variable came out of #3152, but it is opt-in, so tools that build backups on this command (for example sfdx-hardis org monitor backup) silently miss types by default.

Steps to reproduce

Run the same command five times in a row against one sandbox, without and then with batching:

sf project generate manifest --from-org <alias> --include-packages managed,unlocked --name runN --json
SF_LIST_METADATA_BATCH_SIZE=20 sf project generate manifest --from-org <alias> --include-packages managed,unlocked --name batchN --json

Expected result

The same complete list on every run, or a non-zero status or a warning when a listMetadata call fails.

Actual result

Without batching, the five runs returned 66, 81, 101, 100 and 73 types. Core types were missing in some runs: CustomObject, Flow, LightningComponentBundle, Layout, PermissionSet, Profile. Every run had "status": 0 and "warnings": [], and the debug log shows no error for the dropped types.

With SF_LIST_METADATA_BATCH_SIZE=20, all five runs were identical: 110 types and 13,513 members, about 150 seconds each.

Another org showed the same pattern (47 to 63 types across three runs).

System information

• @salesforce/cli/2.155.7, darwin-arm64, Node 24.17.0; also on ubuntu-latest in GitHub Actions
• API version 67.0 / 68.0

Suggestions

1. Batch the listMetadata calls by default (for example 20), or
2. at least report the failed types as warnings, or return a non-zero status, so callers can detect an incomplete manifest.

Related: #3152.