task: #3622591 Update @vardot/varbase-e2e to 2.0.5 for the Canvas editor step fix

Issue: #3622591 Plan: release Varbase Project 11.0.9

What this changes

Bumps @vardot/varbase-e2e from ^2.0.4 to ^2.0.5:

File	Change
package.json	"@vardot/varbase-e2e": "^2.0.4" → "^2.0.5"
yarn.lock	regenerated with yarn up @vardot/varbase-e2e@^2.0.5 (yarn 4.17.0); now resolves @vardot/varbase-e2e@npm:2.0.5
cucumber.js	header comment varbase-e2e (>= 2.0.4) → (>= 2.0.5)
09-07-canvas-pattern-inserts.feature	comment fix only
09-08-canvas-pattern-reuse.feature	comment fix only

6 insertions / 6 deletions in package.json + yarn.lock, and a comment reworded in each of the two feature files. No gherkin step, scenario or Examples row changed — both files still carry exactly the scenarios MR !105 (merged) split them into.

The feature-file comments were stale after that split. Both said the remaining default patterns are covered by the "library offers all 14" scenario "above", which was true when 09-06, 09-07 and 09-08 were one file. That scenario now lives in 09-06, so the comments name 09-06 explicitly, and 09-07 says the rest of the sample is inserted in 09-08.

Why: what 2.0.5 fixes

@vardot/varbase-e2e 2.0.5 was published to npm today and carries the fix for the Canvas editor open step — Vardot/varbase-e2e#53, PR #54, release 2.0.5. The step now:

• keeps to one deadline budget inside its cucumber timeout, instead of a retry loop that could outlast the timeout it runs under;
• navigates through the gotoUrl helper with a bounded timeout and friendly errors;
• uses smartSettle as the readiness wait before probing the Library toolbar, instead of polling a still-booting React app.

That step timing out under load is what failed the 11.0.9 tag pipeline (968906) four runs in a row on 09-drupal-canvas-d, every time on When I open the "<name>" Canvas page in the editor with Error: function timed out … 180000 milliseconds. The 11.0.9 tag was created and then deleted from both drupal.org and the GitHub mirror because of it. 11.0.9 will be re-tagged once this is merged and green.

Relationship to MR !105 (merged)

This is the second half of the same fix. MR !105 (merged) (merged as 049304c) was the load-relief half: it split 09-06 into 09-06/09-07/09-08 and made the cucumber retry configurable. Its pipeline 969009 was fully green, 35/35 — canvas-d 237s, the new canvas-e 607s and canvas-f 321s, each passing on its first attempt, against 500–1615s and repeated failures before the split.

This MR is the library half: the step itself no longer blows its own timeout.

What was verified, and what was not

Verified locally in this checkout:

• node --check cucumber.js passes.
• package.json parses as JSON and reads ^2.0.5.
• yarn.lock resolves @vardot/varbase-e2e@npm:2.0.5 with a new checksum, and the workspace entry reads ^2.0.5.
• The commit's parent is the canonical 11.0.x head 049304c, and only the five intended paths are in the diff.

Not verified, and this is the open risk: the 2.0.5 step fix has not yet been observed to survive a slow runner. It is a one-deadline rewrite of a step that only ever failed under load, and nothing here has reproduced that load. This MR's own pipeline is its first real test. A green run proves the step works; it does not on its own prove the timeout is gone, because the same job has passed on a fast runner before while failing on a slow one. No local cucumber run was possible in this checkout — node_modules is not installed here — so the suite is unproven until CI runs it.

AI-Generated: Yes

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