fix(content): curate slash command blocks with Labs

[3mdistal]

Problem

A new Content page exposed the full structured-block registry in its slash menu, including specialized developer formats and Builder-specific blocks that were irrelevant outside Builder-connected collections.

Result

• Keeps the default slash menu focused on essential writing and media blocks.
• Moves advanced code, layout, visual, and developer-documentation block groups behind user-controlled Settings → Labs toggles.
• Shows Builder block formats only when the page is a direct child of a Builder-connected collection.
• Keeps every block registered for rendering and round-tripping.
• Fixes the shared Labs mutation/registry boundary so Settings toggles persist in development and through the HTTP action surface.

Validation

• pnpm --filter content exec vitest --run app/components/editor/registrySlashItems.test.ts — 15 passed
• pnpm --filter content exec vitest --run app/components/editor/SlashCommandMenu.test.ts — 37 passed
• Builder direct-parent database test — 1 passed
• Core Labs and action-discovery tests — 39 passed
• pnpm --filter content typecheck — passed
• guard:i18n-changed-copy — passed
• Real-interface QA — verified all four Labs controls, toggle persistence across reload, enabled Code/Code Tabs insertion choices, and the curated default menu with specialized and Builder-only blocks absent

The repository-wide guard:i18n-catalogs command still reports the existing catalog/baseline backlog (2,955 issues); this change adds translated strings for every configured Content locale.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes — looks good ✅

Review Details

Code Review Summary

This incremental review covers PR #5616's latest head. The change narrows Content's registry-derived slash menu to the core authoring surface, adds four Labs-controlled groups for advanced code, layouts, visuals, and developer documentation, and gates Builder block formats on the document being a direct child of a Builder-connected collection. It also repairs the shared Labs registry boundary so settings mutations remain visible across development/action module instances.

The approach is sound: the registry remains available for rendering and round-tripping, the new policy fails closed for unknown block types, and the Builder context is computed server-side before being passed into the editor. Three independent balanced code-review passes found no new confirmed bugs or regressions, and the focused tests reported by the agents passed. No prior review threads required resolution or were duplicated.

Risk assessment: Standard, because this changes shared state/action plumbing and Content authoring behavior, but not authentication, payments, schema, or destructive data paths.

Findings

No actionable findings.

🧪 Browser testing: Attempted full visual verification, but Chrome MCP automation tools were unavailable. The dev server was healthy, and live action checks confirmed Labs default-off behavior plus builderBlocks=true only for a seeded direct Builder child; UI-level verification should be rerun when browser tooling is available.