Add configurable concurrency limits to prevent OOM in findChangedDependencies

[Brookke]

Problem

When running chromatic --only-changed after a rebase with many dependency changes in large monorepos, the CLI encounters OOM (Out of Memory) errors.

Cause

findChangedDependencies.ts uses nested Promise.all() calls that spawn unlimited concurrent operations:

• Outer loop: All changed manifest/lockfile pairs process in parallel
• Inner loop: For each pair, all baseline commits compare in parallel

Real-world scenario

715 manifest/lockfile pairs × N baseline commits = 1,430+ concurrent getDependencies() calls, each parsing large lockfiles and building memory-intensive dependency graphs → immediate OOM crash.

Proposed solution

Cap the concurrency to prevent memory usage from growing too high.

This PR

This PR adds per-level configurable concurrency limits using p-limit (already used elsewhere in the CLI):

1. Package-level concurrency: Limits how many manifest/lockfile pairs are processed simultaneously
2. Baseline-level concurrency: Limits how many baseline commits are compared per package

Default behavior: Unlimited (same as before) - no breaking changes

Opt-in limits: Users experiencing OOM can set environment variables to control concurrency

Does it work? Yes

I have tested this solution locally by doing the following:

1. Setting package level concurrency to 300 - leaving baseline at unlimited
2. Creating a branch from a really old commit
3. Running chromatic
4. Rebasing
5. Running chromatic again (memory usage over time remains under 4GB)

Final solution

I don't expect this PR is the final solution, but sharing so that Chromatic can experiment. I would expect that some sensible defaults should be applied to the CLI or a single config option with a single plimit limiter is needed rather than two.