fix(dev-tools): restore Query Tool's persisted query + clear FileAsset example warnings (#36692)

[AP2300]

Summary

Fixes #36692 — addresses both items from @hmoreras' QA round on the merged #36781.

1. Query Tool did not persist the query (the QA blocker)

DotQueryToolStore composes the shared withPersistedQuery() feature correctly and did restore the last query — but the feature's onInit runs when the store is constructed, i.e. before the component's ngOnInit, which then unconditionally wrote the q URL param over it:

const query = params.get('q') ?? '';
this.store.setQuery(query);   // '' when you arrive from the Dev Tools menu

Arriving from the menu carries no q, so the restored value was replaced by '' a tick after it was restored. Query Tool is the only one of the three dev tools that reads URL params — which is exactly why ES Search and Velocity Playground kept their queries and this one did not. The shared helper in libs/data-access/dot-localstorage/ was never at fault and is unchanged.

The param is now applied only when the URL actually carries q. params.has('q') rather than a truthiness check, so a shared ?q= link still clears the editor instead of silently resurrecting the previous query. Deep links keep winning over the restored value and still auto-run; a restored query is left in the editor unexecuted, matching the sibling dev tools.

Worth knowing for re-testing: localStorage itself was never corrupted. The debounced write pipeline's skip(1) happened to swallow the stray '', so the stored entry survived — the query was only missing from the UI. Inspecting Application → Local Storage would have looked healthy.

2. Velocity Playground example ran with warnings

The pull files example referenced $f.fileSize, which is not a contentlet property — it resolved to null on every pulled file, so running the example greeted the user with five NULL_METHOD_RESULT warnings and printed the literal $f.fileSize in the output (the screenshot on the issue).

Size is a metadata-backed getter on FileAsset (getFileSize() → getMetadata().getSize()), reachable through the fileAsset binary field (FileAssetAPI.BINARY_FIELD, and FileAssetMap extends FileAsset). The example now reads $f.fileAsset.fileSize. fileName and mimeType do resolve on the contentlet, which is what made the mistake easy to miss.

I audited the other three Velocity examples and the Query Tool / ES Search example catalogs: all references resolve. The warnings banner is Velocity-only — it is fed by the VTL endpoint's CollectingInvalidReferenceHandler, so the other two portlets have no equivalent surface to clear.

Also checked (no code needed)

Three acceptance criteria on the issue are still unticked but were in fact delivered by #36781 — I verified rather than reimplemented:

• Shared persistence helper lives in libs/data-access/src/lib/dot-localstorage/ (not duplicated per portlet)
• All three portlets wire a Clear action to store.clearPersistedQuery() in their templates
• Velocity's history / splitter storage is reconciled with the persisted-query key

Test plan

• portlets-dot-query-tool-portlet — 58 tests
• portlets-dot-velocity-playground-portlet — 124 tests
• nx affected -t test --base=origin/main — 2,726 tests across 4 projects
• nx affected -t lint + nx format:check clean
• Manual (for QA): type a query in Query Tool, switch to another portlet, come back — query is restored
• Manual (for QA): same round-trip in ES Search and Velocity Playground (regression guard — these already worked)
• Manual (for QA): open a shared ?q=... Query Tool link — the deep link wins over the stored query and auto-runs
• Manual (for QA): run the Velocity pull files example on an instance with files — no warning banner, sizes render as numbers

The Velocity fix was verified by reading the Java (FileAssetAPI, FileAsset.getFileSize(), ContentMap's binary-field branch), not by running it against an instance — worth an extra look during QA.

Testing notes

The new regression coverage sits in a dedicated describe that uses the real store. Every other describe in that spec mocks DotQueryToolStore, so the store-onInit-before-ngOnInit ordering was structurally invisible to them — which is how this shipped green. It covers restore-on-reopen, deep-link precedence, and that the stored entry is never erased. Confirmed failing first (expected '' to be '+contentType:Blog'), then passing.

🤖 Generated with Claude Code

This PR fixes: #36692