WE2-968: Add Angular and React examples

[svenzik]

• Add Angular example
• Add React example
• build(deps): migrate from Angular 19 to 20
• build(deps): migrate from Angular 20 to 21
• build: Angular example version bump to 2.1.0-beta.0

Supersedes #58
Closes #58

To fix the issue, the message handler should validate incoming messages before acting on them. In a service worker context, event.origin is not the primary control; instead, you can validate the sender (event.source) and enforce that the data is of the expected form (e.g., a known string command). This avoids responding to malformed or unexpected messages and aligns with the spirit of origin verification: don’t trust arbitrary senders or payloads.

The minimal, behavior‑preserving mitigation here is:

• Ensure event.source is present and looks like a Client object with an id. If not, ignore the message.
• Restrict processing to messages where event.data is one of the known string commands. We already have a switch (event.data) over a finite set of string literals; we can precede it with a guard that ensures typeof event.data === 'string'. Non‑string or unexpected data will be ignored instead of falling into the switch (which currently has no default but still conceptually “handles” any value).

Concretely, in examples/web-eid-angular-example/public/mockServiceWorker.js, inside the self.addEventListener('message', async function (event) { ... }) block:

• Add a check right after entering the handler to verify event.source exists and has an id, and that typeof event.data === 'string'. If any of these checks fail, return early.
• This keeps existing functionality for legitimate clients (they already send those specific strings) but drops messages from unexpected sources or with unexpected payload types.

No new imports or external libraries are required.

General fix: For message handlers, validate that the message comes from a trusted sender before acting on event.data. In a service worker context, this usually means validating the event.source (a Client) and/or keeping track of clients that have explicitly opted in, and ignoring messages from unknown clients.

Best fix here, without changing external behavior: maintain a set of known client IDs that are allowed to issue control messages, and only process the switch (event.data) if the message’s clientId belongs to that set or if it is the initial message used to register/activate mocking. Since we already have activeClientIds, we can (1) treat 'MOCK_ACTIVATE' as the opt‑in message that registers a client as trusted, and (2) ignore all other message types from clients that are not yet in activeClientIds. This preserves current semantics for legitimate clients (they send MOCK_ACTIVATE first, as MSW expects) while preventing arbitrary pages from sending deactivation or shutdown messages.

Concretely in examples/web-eid-react-example/public/mockServiceWorker.js:

• After obtaining the client (and before the switch), add a guard that allows 'MOCK_ACTIVATE' unconditionally, but for all other event.data values, returns early unless activeClientIds already contains clientId.
• Leave the existing switch body unchanged so functionality is preserved.
• No new imports are needed; we reuse the existing activeClientIds set.