Add end-to-end test coverage

## Context

Derived from requirement **RF-PCE-006**

## Scope

Add end-to-end test coverage for the editor's real use cases, starting with the one the
application exists for: filling in the form and getting a valid `publiccode.yml` out.

The current suite is unit-level only — eleven `*.spec.ts` files under `src/app/`
covering the pure helpers (adapter, serializer, linter, semver, URL utils) plus one
component test, `EditorDependsOn.spec.tsx`. They run under Jest with `@swc/jest` and
jsdom. Nothing exercises the application as a user meets it, so the paths most likely to
break in production — import, validate, export — are the ones with no coverage at all.

Use cases worth covering:

- Filling the form from empty and producing a valid file, including the multi-language
fields and the repeatable sections (features, screenshots, videos, contacts).
- Importing an existing `publiccode.yml`: file upload, direct URL, GitLab repository URL.
- Validation: a valid file passes; an invalid one surfaces the expected errors and
warnings.
- Getting the result out: copy and download.
- The country-specific sections, driven by `VITE_DEFAULT_COUNTRY_SECTIONS` and the
`countrySpecific` query parameter.

Two properties of this app shape how the tests have to run:

- **The validator is WebAssembly.** It is Go compiled to `public/main.wasm` and loaded
at runtime through `wasm_exec.js`. jsdom will not do — the tests need a real browser
running a real build, with `npm run build:wasm` having produced the artefact. CI
already installs Go, so the pieces are there.
- **The app persists to `localStorage`** (`yaml-storage`, `warnings-storage`,
`itCountrySpecific-store`). Tests have to start from a known state, or they will pass
or fail depending on what the previous test left behind.

Picking the framework belongs to the design phase, but it is worth noting that these
constraints narrow the field quite a bit, and Playwright covers them without much
ceremony: browser contexts are isolated by default, which takes care of the
`localStorage` problem; file uploads and downloads are first-class, which the import and
export cases both need; and its GitHub Actions integration is well-trodden. Unless
something argues against it, that is the reasonable starting assumption.

## Affected areas

- New end-to-end suite, kept separate from the Jest unit tests so `npm run test` stays
fast.
- `package.json` — a script for the new suite; Jest config is inline here too.
- `.github/workflows/test.yml` — currently `npm ci` → `build` → `lint` → `test`; the
e2e run needs to be added, serving the built `dist/`.
- `src/app/components/Editor*.tsx` — stable selectors for the fields the tests drive;
worth avoiding brittle CSS-path selectors.

## Non-functional constraints

- **RNF-PCE-002 — Cloud-native architecture**: the suite must run in the existing
GitHub Actions pipeline on every pull request, not as a manual local step.
- **RNF-PCE-006 — Long-term sustainability**: end-to-end tests are the ones that rot
fastest. They need to be fast enough that nobody is tempted to skip them, and stable
enough that a red build means a real regression — a flaky suite that gets ignored is
worse than no suite.

## Acceptance criteria

- [ ] End-to-end tests run against a real browser and a real build, with the WASM
validator actually loaded
- [ ] Filling the form from empty through to a valid `publiccode.yml` is covered
- [ ] All three import paths are covered: file upload, direct URL, GitLab URL
- [ ] Validation is covered for both a valid and an invalid file
- [ ] Copy and download are covered
- [ ] Each test starts from a clean `localStorage`
- [ ] The suite runs in CI on every pull request and fails the build on regression
- [ ] Unit tests stay separate, so `npm run test` remains fast
- [ ] The suite is stable: no known flaky tests at merge time

## Related

- #189 — "Improve the automated testing", open since before this requirement existed;
this issue is the concrete plan for it
- #646 — automated accessibility checks, which will run in the same CI pipeline and may
share the browser setup

Start by reading package.json and .github/workflows/test.yml, then inspect the existing src/app/components/Editor*.tsx tests and run npm run build:wasm followed by the current test commands. Define the separate browser suite around the listed import, validation, form, copy, and download flows, using clean browser contexts and the built dist/. Done means the real-browser tests pass locally and in CI on every pull request while npm run test remains fast.

Written by the indexing model from the issue text.