fix: bound concurrent Sass renders

[wessmeister]

Pull request checklist

• Docs have been reviewed. No update is needed because this changes internal scheduling only.
• Build (pnpm run build) was run locally and passed.
• Tests (pnpm test) were run locally and passed.
• Prettier (pnpm run prettier) was run locally and passed.

Pull request type

• Bugfix
• Feature
• Refactoring (no functional changes, no API changes)
• Build related changes
• Documentation content changes
• Other

What is the current behavior?

Each concurrent transform calls sass-embedded's legacy render() API. That API creates a compiler process per call, so Dart Sass process fan-out currently grows with the number of in-flight stylesheets.

GitHub Issue Number: #711

Closes #711.

What is the new behavior?

• Sass render calls are queued per plugin instance and limited to Stencil's validated maxConcurrentWorkers value, which currently defaults to 8 and becomes 4 in CI.
• A worker setting of 0 still allows one render at a time, so disabling Stencil workers cannot deadlock Sass compilation.
• Existing plugin options, Sass output, diagnostics, and dependencies remain unchanged. No new runtime dependency or public option is introduced.

Does this introduce a breaking change?

• Yes
• No

Testing

• Added regression coverage that reproduced six simultaneous renders with maxConcurrentWorkers: 2 before the change and now observes a peak of two.

• Covered maxConcurrentWorkers: 0 and confirmed queued work continues after a Sass compilation error.

• pnpm run build, all 41 unit tests, formatting, package dry run, and the Stencil v4 integration fixture pass.

• The public 50-component reproduction produced the following results:

  Metric	Stock 3.3.2	This change
  Duration	1.51 s	2.30 s
  Peak Dart processes	26	8
  Peak Dart RSS	145.1 MiB	41.6 MiB

  The stock peak varies with process scheduling. The patched build remained at Stencil's configured limit of 8. All 152 files in the generated component output were byte-identical.

• A 200-component run also remained capped at 8 Dart processes.

Other information

Using a reusable AsyncCompiler would avoid process startup per transform, but its public modern API cannot consume this plugin's legacy importer and function options. This patch preserves that compatibility while fixing the unbounded process fan-out. It does not prevent a later migration to the modern API.

[johnjenkins]

LGTM - Great work!

[johnjenkins]

thanks again for the great contribution, this was released in v3.3.3