feat: ClipboardReadAction + typed JsBuilder.callback primitive

[Artur-]

Adds a typed server-callback primitive to the trigger framework and the first action that needs it: reading the user's clipboard.

JsBuilder.callback(...) — three overloads — allocates a $N placeholder for a JS function (payload) => … that, when called from client JS, deserialises its first argument to T via Jackson and invokes the handler on the UI thread:

• <T> callback(Class<T>, Consumer<https://github.com/nullable T>)
• <T> callback(TypeReference<T>, Consumer<https://github.com/nullable T>) for
  parameterised types (List<X>, Map<String, X>, …)
• callback(SerializableRunnable) for the no-payload case

Each call registers a fresh ReturnChannelRegistration on the trigger's host node; channels are not deduplicated across calls (the previous per-(action, host) dedup in PromiseAction was a micro-opt that didn't survive generalising the primitive). Channels go away when the host node detaches.

PromiseAction is rewritten on top of callback(...). Its previous single-channel (boolean, message) tuple dispatch is
two callbacks — a runnable for the success leg, a String-typed consumer for the error leg — and the rendered JS becomes
.then(()=>$ok()).catch(e=>$err(msg)). The channelByNode map and inline dispatch method are gone; PromiseAction now has no state beyond the two optional consumers.

ClipboardReadAction is a direct Action subclass (not PromiseAction, because the resolved value is a typed payload, not just success/failure). It takes a SerializableConsumer<https://github.com/nullable ClipboardPayload> handler that
receives the clipboard contents on success or null on any failure (rejection, empty items, unsupported API). The handler is single because clipboard read failures rarely carry useful detail — callers who need success/error distinction can switch to PromiseAction-style.

ClipboardPayload(https://github.com/nullable String text, https://github.com/nullable String html) is the typed payload — first ClipboardItem's text/plain and text/html representations.

The actual clipboard read + {text, html} extraction lives in flow-client/src/main/frontend/Clipboard.ts, mirroring
Geolocation.ts: it attaches a readPayload() function to window.Vaadin.Flow.clipboard, imported by Flow.ts so it loads
with the framework. The Action's appendStatement just renders the routing glue — window.Vaadin.Flow.clipboard.readPayload() .then(p=>$N(p)).catch(()=>$N(null)) — keeping the multi-statement
JS out of Java string concatenation.

The IT (TriggerClipboardReadView/IT) shims navigator.clipboard.read with a fake ClipboardItem that resolves
the two MIME types and a rejecting variant, exercising the TS layer end-to-end and asserting the server-side status div reflects the payload (or "null").

[github-actions]

Test Results

 1 420 files  +2   1 420 suites  +2   1h 21m 30s ⏱️ + 2m 55s
10 005 tests +5   9 936 ✅ +5  69 💤 ±0  0 ❌ ±0 
10 480 runs  +5  10 409 ✅ +5  71 💤 ±0  0 ❌ ±0 

Results for commit ca5930f. ± Comparison against base commit 3424caa.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mshabarov]

Couple of things to think about, but not blocking.

[mshabarov]

One possible potential improvement could be if ClipboardReadAction would extend PromiseAction and PromiseAction would have a generic type. JsonNode then would not leak into app code through a Success wrapper; every subclass won't write an adapter to unwrap it.

What would get better:

• PromiseAction — payload type is generic; framework Jackson-decodes once, onSuccess is Consumer<@nullable T>.
• Success is gone — one fewer wrapper.
• Subclasses drop their adapters — CopyTextToClipboardAction extends PromiseAction; RequestFullscreenAction extends PromiseAction.
• Type-safe at the API surface — the compiler enforces the payload shape; JsonNode never leaks.
• One pattern for value-returning promises — future built-ins (clipboard read, share, file picker) reuse PromiseAction instead of inventing adapters.

Then:
ClipboardReadAction extends PromiseAction<ClipboardPayload>
CopyTextToClipboardAction extends PromiseAction<String>
RequestFullscreenAction extends PromiseAction<Void>

And there one "but": this is an internal API so far, so no high priority and maybe no need for now - just something to think about in the code design.

[mshabarov]

In the future we may want to add more content types (already have plans for images), this can bring incompatible changes. But not blocking this intermediate low level PR I think.