v3.22.0: the event action uses the Simulator's forms (all modelled events)

The test-script event action edited its fields as a JSON textarea and only
accepted the four events events.py builds; every other event needed the raw
envelope action with hand-copied hex.  It now renders the same EVENT_FORMS
form the Phone tab's send dialog uses, for every modelled event (29; no
release gating - a script may target another card).

- PWA: the field renderer/collector is shared (eventFormFieldsHtml /
  eventFormValues / eventFormPatternError / eventFormSrc / eventFieldGroupsUpdate);
  the Phone tab keeps its ids, its release gating and its onchange updaters,
  the step editor uses test-f-ev- ids, the generic group updater and a live
  Event data (hex) preview with the one-ENVELOPE check.  The event select
  lists all EVENT_FORMS events (the numeric keys are decimal strings -
  parseInt(k, 10)); the action stores the collected fields, the built data
  and the event's source (fixed cfg.src or the cfg.srcField input - the
  action never carried src before, so MT call / IMS registration / slices
  could not be network-sourced).  The JSON textarea is gone.
- engine: the `event` action keeps `fields` validation for the four
  server-built events (a stray data hex is ignored) and accepts the
  form-built `data` for every other event - hex-validated and checked
  against events.EVENT_DATA_MAX (244, the one-ENVELOPE budget; server.py's
  _EVENT_DATA_MAX now reads it from events.py).  The runner builds the four
  at run time (fresh host clock) and sends the stored data for the rest.
- tests: the engine's data path (accepted / missing / malformed / oversized,
  the four still fields-built), the runner sending the data (fake scc), the
  editor's collect/prefill/patterns/source (Node), the shared helpers.
  Docs: test-scripts.md, api.md, help EN/RU.  Tests: 838 frontend +
  797 Python; sw cache simple-v401.

docs/api.md

@@ -720,8 +720,10 @@ callers.
 
 **Action steps** (`type: "action"`): `kind` is `envelope` (`event`, `data`,
 optional `src` - the device-identities source override),
-`event` (`event` name or hex + `fields`, optional `src` - the semantic event
-download for 0x03/0x0B/0x12/0x1D), `menu-select` (`item_id` 1-255, or `text` +
+`event` (`event` name or hex + `fields` for the four server-built events
+0x03/0x0B/0x12/0x1D, or the PWA form's built `data` hex for any other event -
+validated as hex and against the one-ENVELOPE budget at load; optional `src`,
+the device-identities override), `menu-select` (`item_id` 1-255, or `text` +
 `mode` `exact`/`contains` (case-insensitive by default; `case_sensitive: true`
 forces an exact-case match) - the text is resolved against the card's cached
 SET UP MENU, which is refreshed whenever the card sends the menu), `file-write`

docs/test-scripts.md

@@ -259,7 +259,7 @@ consecutive runs continue correctly.
 | kind | params | notes |
 |---|---|---|
 | `envelope` | `event` 0–255, `data` hex (optional), optional `src` | ENVELOPE(Event Download) with raw data; `src` overrides the device-identities source (`82` terminal / `83` network) |
-| `event` | `event` (name or hex), `fields` (object), optional `src` | semantic ENVELOPE(Event Download) for 0x03/0x0B/0x12/0x1D (see below) |
+| `event` | `event` (name or hex), `fields` (object) or `data` (form-built hex), optional `src` | semantic ENVELOPE(Event Download): the four server-built events from `fields`, every other event from the editor's `data` (see below) |
 | `menu-select` | `item_id` 1–255 **or** `text` + `mode` `exact`/`contains` (+ `case_sensitive: true` for an exact-case match — the default is case-insensitive; the step editor's **Match case** choice writes it), not both | ENVELOPE(Menu Selection); the text is resolved against the card's cached menu - refreshed whenever the card sends SET UP MENU, so it follows the applet's install parameters |
 | `file-write` | `path`, `data`, `mode` `auto`/`binary`/`record`, `record` 1–255 | UPDATE BINARY/RECORD |
 | `file-read` | `path`, `mode`, `record` | READ BINARY/RECORD; verify with `check.data` |
@@ -278,10 +278,17 @@ a remote entity through OTA/RFM, TS 102 223 §7.5.9): assert the change with
 
 ### Semantic events (`kind: "event"`)
 
-The server builds the event objects for the events a test needs most; an
-event without a builder goes through the raw `envelope` action, whose data hex
-the Phone tab's event form shows (**Event data (hex)**, copyable).  Both
-actions take the same optional `src` device-identities override.
+The step editor renders the **same form the Phone tab's send dialog uses**
+(`EVENT_FORMS`), for every modelled event - no release gating (a script may
+target another card).  The four events the server builds (`0x03`/`0x0B`/`0x12`/
+`0x1D`) travel as `fields`: the server validates them at script load and builds
+the objects at run time (so the data-connection host clock is fresh).  Every
+other event carries the form's built hex as `data` (the editor shows it live
+under the form, with the one-ENVELOPE check; the engine validates it and the
+single-envelope budget at load).  The `src` device-identities source comes from
+the event itself (e.g. MT call and IMS registration are network-sourced) or
+from the form's source field; an explicit `src` overrides it.  Both the
+`event` and the raw `envelope` action take the same optional `src`.
 
 ```json
 {"type": "action", "kind": "event",