test(frontend): add end-to-end test suite

[andre8244]

TL;DR

• What it adds: browser end-to-end tests (Playwright). It runs the real app against a real backend and signs in through the real Logto login form.
• Where each part runs:
  • Full browser suite: on a PR only when the run-e2e label is added, plus every merge to main, on demand and weekly. It uses a Logto tenant reserved for CI.
  • QA smoke: read-only checks against QA after each deploy.
  • Production is never touched.
• Merge rule: A PR can be merged only once the suite has passed on its last commit. PRs that change only documentation pass without a run.
• Coverage:
  • Sign-in and the session.
  • All 21 organization role × technical role pairs (menus, sections they can open, buttons they're offered), plus hierarchy scoping of the list views.
  • Creating and editing companies, systems and users.

📋 Description

Adds browser-level end-to-end tests. The API is already covered
end-to-end by the authorization suite, but nothing exercised the UI.

The suite drives the real application against a real backend, signing in
through the actual login form as the users the existing test fixture
already provides.

Where each layer runs

Layer	When	Against
Authorization spec check	every push to main and every pull request targeting main	nothing external — reads the repo's own files, about a second
Browser suite (fullstack)	on a pull request when the run-e2e label is added, merge to main, on demand, weekly	the whole stack built and booted on the runner, with a Logto tenant dedicated to CI
QA smoke (smoke)	after each QA deploy	the deployed QA environment, read-only

Production is never contacted. The CI tenant is separate from the
development and QA ones, so provisioning and removing its test users
collides with nobody.

Running it on a pull request

Add the run-e2e label to run the browser suite. The result is the
e2e/fullstack status on the latest commit; every push resets it, so a
pull request merges only once the suite passed on its last commit.
Documentation-only pull requests pass without a run.

Show tests included

Sign-in (2)

• a saved session lands on the dashboard without a round trip to Logto
• an unauthenticated visitor is sent to Logto

Permissions (42 — every organization role × technical role pair)

• each pair is offered exactly the navigation its permissions allow
• each pair reaches the sections it may read and is refused the rest

Action controls (21 — one per pair)

• each pair is offered exactly the actions its permissions allow inside a
  page, which is where a hidden section still leaves a visible button

Hierarchy scoping (6)

• /resellers and /customers list the caller's own branch and nothing
  outside it, from a distributor down to a reseller
• /users lists a customer organization's own members only

Session (4)

• a live session survives a reload without going back to Logto
• a tab with no JWT pair re-mints one silently
• a refusal offers a way back from the forbidden page
• a refusal leaves the rest of the session usable

Organizations (3)

• creates a company and lists it
• refuses a company with no VAT number
• edits a company and keeps the change

Systems (3)

• lists a new system and filters down to it
• opens the detail view for a system
• stops offering to regenerate the secret once the system registers

Users (4)

• creates a user with a role and lists it
• changes the assigned role and keeps the change
• archives the user
• refuses a user with no role assigned

QA smoke (4, read-only, against the deployed environment)

• serves a healthy backend
• sends an anonymous visitor to the identity provider
• signs in, loads the dashboard and signs out
• renders a list page

Test data

The tests assume no company, user or system exists beforehand. Each one
creates what it needs, named under a reserved prefix, and removes it
afterwards; the cleanup refuses to touch anything outside that prefix,
and each file sweeps leftovers before it starts, so a run that crashed
earlier cannot influence the next. The database is new on every run.

What must be prepared once, per tenant, is the identity provider: an
initialized Logto tenant with its roles and its owner account. The
secrets are listed in .github/workflows/README.md.

Notes

Three changes reach the application code; two of them change what
production builds do:

• Pinia Colada devtools out of production builds. App.vue mounted
  PiniaColadaProdDevtools, which ships the panel in every build. It now
  mounts PiniaColadaDevtools, which is dev-only, so the panel no longer
  appears on qa or production.
• Re-authentication keeps the current page. When the session dies
  mid-visit, stores/login.ts saves the page the user is on before
  redirecting to Logto, so they come back there instead of on the
  dashboard.
• A build-time VITE_E2E flag, set only for test builds, disables
  background refetching and the devtools panel, because both interfere
  with the tests. It has no effect on dev, qa or production builds.

Also adds a cheap authorization check to the existing pipeline: it fails
when an endpoint ships without a declared permission, or when the test
fixture names a role no configuration defines.

[github-actions]

🔗 Redirect URIs Added to Logto

The following redirect URIs have been automatically added to the Logto application configuration:

Redirect URIs:

• https://my-proxy-qa-pr-195.onrender.com/login-redirect

Post-logout redirect URIs:

• https://my-proxy-qa-pr-195.onrender.com/login

These will be automatically removed when the PR is closed or merged.

[github-actions]

🗑️ Redirect URIs Removed from Logto

The following redirect URIs have been automatically removed from the Logto application configuration:

Redirect URIs:

• https://my-proxy-qa-pr-195.onrender.com/login-redirect

Post-logout redirect URIs:

• https://my-proxy-qa-pr-195.onrender.com/login

Cleanup completed for PR #195.