feat: #3620177 Initialize the Varbase Canvas Base recipe

Initializes the drupal/varbase_canvas_base recipe on the 1.0.x branch, which until now held a single empty commit.

Issue: #3620177 Initialize the Varbase Canvas Base recipe

AI-Generated: Yes

What this adds

A new drupal-recipe package, drupal/varbase_canvas_base, branch 1.0.x, version 1.0.x-dev. It requires drupal/core: ~11.4.0, drupal/canvas: ~1 and drupal/canvas_override: 1.0.x-dev.

recipe.yml declares type: Varbase Canvas, config.strict: false, install: [canvas, canvas_override], and 17 permission grants moved verbatim out of Varbase Content Base:

• content_editor (2): create canvas_page, edit canvas_page
• content_admin (5): administer folders, administer patterns, create canvas_page, edit canvas_page, publish auto-saves
• site_admin (10): administer components, administer content templates, administer folders, administer page template, administer patterns, create canvas_page, delete canvas_page, edit canvas_page, edit canvas global regions, publish auto-saves

Ten files in total: .gitignore, .gitlab-ci.yml, .gitlab/issue_templates/default.md, .gitlab/merge_request_templates/default.md, AGENTS.md, CHANGELOG.md, README.md, composer.json, logo.png, recipe.yml.

This recipe is applied by Varbase Starter only — deliberately not by Varbase Content Base, Varbase Media Base, Educare, Horizon Aid or RightUp.

What was deliberately left out

Each of these was decided, not missed:

• canvas_icon_picker is not here. It stays with Varbase Admin Base — see #3620064 and #3620066.
• canvas_interactive_toggle is not here. It would be new shipping surface, not a move.
• The canvas module install stays in Varbase Media Base. Educare, Horizon Aid and RightUp each carry 58-80 canvas.component / canvas.content_template config keys, none of them installs canvas itself, and all three apply Varbase Media Base directly rather than through Varbase Starter — moving the install would break them. This recipe still lists canvas in its own install:, which is harmless and idempotent.
• No Canvas Override permissions are granted (use canvas override, reset canvas layout, edit canvas default template, administer canvas override). No Varbase recipe has ever granted them. That is a real gap, and it is being decided separately rather than as a side effect of this move.
• administer code components is not granted. Canvas marks it restrict access: true because it executes JavaScript.
• administer brand kit is not granted, so the permission set here is a pure move, nothing added.
• canvas_translate stays in Varbase i18n Base (a language concern), and the canvas_html_inline / canvas_html_block text format permissions stay in Varbase Editor Base (an editor concern).

Testing done

• Applied green with drush recipe ../recipes/varbase_canvas_base on an existing Varbase 11 DDEV site.
• Fresh drush site:install varbase (which applies Varbase Starter) on a clean DDEV site, with the modified Varbase Content Base and Varbase Starter recipes overlaid. Completed successfully. Verified afterwards that canvas and canvas_override are enabled and all 17 permissions are present on content_editor / content_admin / site_admin — identical to a stock build, but now sourced from this recipe.
• The pipeline defined by this MR's own .gitlab-ci.yml was run locally with gitlab-ci-local before pushing: build:composer-validate PASS, validate:yaml-lint PASS.
• The project's first pipeline on the forge, #943419, passed: build:composer-validate success, validate:yaml-lint success.

Testing NOT done

• No browser / UI testing of the Canvas editor itself.
• No upgrade-path testing on an existing site.

Known, unresolved follow-up work

1. Varbase Content Base still needs to drop the canvas_override install, the drupal/canvas_override require and those 17 grants, and Varbase Starter still needs to apply this recipe and require drupal/varbase_canvas_base: ~1.0.0. Both changes are written locally but are not yet filed as issues or MRs.
2. Educare, Horizon Aid and RightUp lose those Canvas permissions once Varbase Content Base stops granting them, because they apply it directly and do not require this recipe. That needs its own decision before the Content Base change ships.

Note on the branch

Created as a branch on the canonical project rather than as a drupal.org issue fork: no issue fork exists for #3620177 yet, and creating one needs the "Create issue fork" control on the issue page (an authenticated browser session), which was not available for this run. The token used holds Maintainer on the project. Happy to re-open this from a proper issue fork if maintainers prefer.

Checkpoints:

• File an issue
• Addition/Change/Update/Fix
• Testing to ensure no regression
• Automated unit testing coverage
• Automated functional testing coverage
• UX/UI designer responsibilities
• Readability
• Accessibility
• Performance
• Security
• Developer Documentation
• User Guide Documentation
• Reviewed by human
• Code review by maintainers
• Full testing and approval
• Credit contributors
• Review with the product owner
• Release notes snippet
• Release