Fix Bricks synchronization for empty class sets

[Jan-CoreBunch]

Summary

Fixes Bricks synchronization when Core Framework generates variables but no utility classes, and removes stale CF-owned classes immediately when the final generated class is disabled.

Root cause

• The client returned early when the generated class collection was empty, so update-classes was never called and Bricks variables were not refreshed.
• Empty selector input could be parsed as an array containing an empty string.
• Previously synchronized CF classes were filtered before removed locked-class IDs were calculated, losing the IDs required for stale-reference cleanup.

Changes

• Always invoke class and variable synchronization, including with zero classes.
• Send selector names as an array while retaining normalization for legacy string input.
• Normalize empty input to a real empty array and prevent creation of a blank _c class.
• Run synchronization only after successful stylesheet persistence.
• Calculate removed IDs from the original CF-owned class collection.
• Remove deleted CF IDs from Bricks locked classes and relevant _cssGlobalClasses references.
• Preserve user-created and non-CF classes, variables, categories, and unrelated post settings.
• Preserve variable extraction through StylesheetStorage.
• Keep repeated synchronization idempotent.

Automated validation

• bun run php-test:wp — 26 tests and 47 assertions passed.
• bun run test:www — 23 suites and 147 tests passed.
• bun run build:wp — passed.
• PHP syntax, targeted production PHPCS, Biome, and git diff --check passed.

Manual functional validation

Using Bricks 2.3.11:

1. Saved a variables-only project with no generated utility classes.
2. Confirmed CF variables appeared immediately in Bricks.
3. Enabled a CF class and confirmed it appeared.
4. Disabled the final CF class and saved once.
5. Confirmed it disappeared immediately while variables remained.
6. Confirmed an independent Bricks global class remained untouched.
7. Repeated synchronization without duplicates or additional mutations.

Manual performance validation

Bricks documents	Elements/document	Add class	Remove class
100	25	76 ms	321 ms
1,000	25	78 ms	2.78 s
5,000	25	68 ms	13.54 s
5,000	100	78 ms	19.09 s

All update-classes requests returned HTTP 200 and completed without errors.

Class addition remained effectively constant. Removal scaled approximately linearly because stale CF references must be removed from Bricks post metadata. The 5,000-document cases are considered an extreme-site caveat rather than a blocker for this focused fix. Further optimization can be considered separately if real-world usage demonstrates a need.