docs(factories): fix limit fallback and approval claims in Resource limits

Address review feedback on the Resource limits section:

- "an omitted limit leaves that dimension unbounded" contradicted the
  documented `maxConcurrentSubagents` -> `maxTotalSubagents` fallback in
  factory-patterns.md. Note the exception so a declared total cap is not
  read as leaving concurrency unbounded.
- "the run still needs an approval" is only true for the model-initiated
  `run_factory` path. SDK-initiated `run` and `resume` do not request
  permission (src/factory.ts:292, and the Run and resume section says the
  same), so qualify the claim instead of promising SDK callers a safeguard
  that does not exist.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: examon

nodejs/docs/factories.md

@@ -115,9 +115,9 @@ See [factory-patterns.md](./factory-patterns.md) for composable orchestration pa
 
 ## Resource limits
 
-Limits may be declared in `meta.limits` and overridden per invocation. Every limit is optional and must be positive when present; an omitted limit leaves that dimension unbounded.
+Limits may be declared in `meta.limits` and overridden per invocation. Every limit is optional and must be positive when present; an omitted limit leaves that dimension unbounded, except that an omitted `maxConcurrentSubagents` falls back to `maxTotalSubagents`, so a declared total cap also bounds concurrency.
 
-Set a ceiling only from real knowledge of what the factory costs, or because the user named one. A guessed ceiling does not make a run safer: it stops a healthy run partway with `factory_limit_reached`, after that run has already taken the user's approval and spent credits. An agent authoring or invoking a factory on the user's behalf has no basis for estimating a number, so it should leave `limits` unset and bound the work with the factory's own counters instead. Omitting limits does not remove oversight, because the run still needs an approval and that prompt shows the effective limits first.
+Set a ceiling only from real knowledge of what the factory costs, or because the user named one. A guessed ceiling does not make a run safer: it stops a healthy run partway with `factory_limit_reached`, after that run has already spent credits. An agent authoring or invoking a factory on the user's behalf has no basis for estimating a number, so it should leave `limits` unset and bound the work with the factory's own counters instead. Omitting limits does not remove oversight of a model-initiated run: `run_factory` requests permission first, and that prompt shows the effective limits. SDK-initiated `run` and `resume` do not request permission, so an SDK caller that wants a ceiling sets it deliberately, from the cost it already knows.
 
 ```js
 // Only when the cost profile is known, or the user asked for this ceiling.