fix: #3621384 Take the access-restricted step from varbase-e2e 2.0.4

Issue: #3621384 Remove the local "the page should be access restricted" step, now ambiguous with @vardot/varbase-e2e 2.0.4

Why

@vardot/varbase-e2e 2.0.4 ships the same step this project defined locally, so Cucumber saw two definitions for one sentence and failed the run with Multiple step definitions match — 2 of the 6 scenarios. Both are the permission-matrix scenarios this step exists for.

Then the page should be access restricted

• Ours: tests/step-definitions/varbase_layout_builder.steps.js:97
• The library's: navigation.steps.js:310

What changed

• Deleted the local step and its doc block from tests/step-definitions/varbase_layout_builder.steps.js, dropped the Then import it was the only user of, and refreshed the @file note.
• Dependency ^2 → ^2.0.4.
• No feature file changes: the sentence is identical.

Keep the library one: it accepts an access-denied page, a log-in form or a redirect to one, it navigates nowhere, and it answers to both phrasings — which is why a local copy of either collides. Documented.

Unrelated, for anyone installing locally: npm install needs --legacy-peer-deps here because stylelint-config-prettier@9 wants stylelint < 15 and the project is on 16. Pre-existing, untouched.

Verified

npx cucumber-js --dry-run: 6 scenarios, 38 steps, nothing ambiguous, nothing undefined (before: 2 ambiguous). The browser suite needs a live site, so CI confirms the rest.

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