2.0.5

What's changed

One fix: the Canvas editor open step no longer outlasts its own timeout under load.

The Canvas editor open step keeps to one deadline budget (#53, #54)

When I open the "<name>" Canvas page in the editor could be killed by cucumber with a bare
Error: function timed out, ensure the promise resolves within 180000 milliseconds instead of
reporting what was not ready. Its retry loop ran up to three attempts of an unbounded
page.goto plus a 45s wait for the Library toolbar, so on a slow runner the attempts outlasted
the step's own 180s timeout and the loop's error was never reached.

Observed on drupal/varbase_project CI, job varbase-e2e: [09-drupal-canvas-d], where the same
commit passed on one pipeline in 821s and failed on another whose job ran 1615s.

What the step does now

• One budget. The step timeout (now 240s) is the whole budget, with a 10s reserve kept back so
  the step can always raise its own error. An attempt starts only while enough budget remains for
  a useful one, so the loop can never be cut off mid-attempt.
• Navigation through gotoUrl. The shared helper gives the friendly "is the dev server up",
  DNS and empty-response messages, and it is bounded by this attempt's slice of the budget.
• smartSettle as the readiness wait. The page is settled — DOM ready, network idle, no
  pending AJAX or timers, no DOM mutation for 250ms — before the Library toolbar is probed,
  rather than polling a React app that is still booting. The retry path settles too, instead of
  sleeping blind.
• A failure now says so. The error names the attempt count, the seconds spent and the
  underlying Playwright message.

gotoUrl takes an optional third argument, {timeout, waitUntil}. Defaults are unchanged and
all six existing call sites pass two arguments, so nothing else behaves differently.

Not covered

No test was added for this, and the fix has not yet been proven against a slow CI runner — the
failure it addresses only appears under load.