Register a Gutenberg block pattern or block variation

I need two things registered for a client's block theme:
1. A block pattern called "Hero CTA" (heading, paragraph, and a centered button) that
   shows up in the pattern inserter under a "Client Sections" category.
2. A block variation of `core/group` pre-configured with a dark background color and
   padding, so editors can insert a "Dark Section" without manually setting five
   attributes each time.

ENVIRONMENT: [WordPress 6.7, full site editing block theme, patterns currently live in
a companion plugin because the theme itself doesn't reliably survive updates]

Build this like a developer shipping FSE patterns to production, in order:
1. Show `register_block_pattern_category()` for "Client Sections" and
   `register_block_pattern()` for the Hero CTA pattern, with the actual block markup
   (the exact HTML comment delimiters WordPress expects, like
   `<!-- wp:heading -->`), registered on the `init` hook.
2. Show the `core/group` block variation registered via JS (`registerBlockVariation()`)
   in an editor script, with `isActive` matching on the specific attribute (e.g.
   background color) so WordPress correctly highlights it as selected in the inserter
   rather than always showing the generic Group block as selected.
3. Flag the category timing edge case: if the pattern category isn't registered before
   the pattern that references it (order of hook execution, or if it's registered on a
   later-priority `init` callback), the pattern silently falls back to "Uncategorized"
   instead of erroring, which is confusing to debug since nothing looks broken, it's
   just miscategorized.
4. Address the duplicate-registration risk explicitly: since patterns live in a plugin
   but this is a block theme, some editors also add local patterns via the theme's own
   `/patterns/` directory. Explain how to check for a naming collision (pattern slugs
   must be unique) and recommend a consistent `clientname/pattern-slug` prefix
   convention to avoid a theme update silently overriding the plugin's pattern.
5. Note that block variations don't need PHP registration at all when they're pure
   attribute presets, only patterns do, and that mixing the two mental models (looking
   for a `register_block_variation()` PHP function that doesn't exist) is a common
   confusion point for developers newer to FSE.

Replace the pattern content and variation attributes with your actual design.