feat(views): pre-fill a result action's form from a fill query (#690)

[tkuhn]

Closes #690.

What

A view's result action (the "add…" button) could pre-fill only the target field. It can now carry its own query, bound to the target resource, whose first result row pre-fills the form:

sub:addAction a gen:ViewResultAction ;
    gen:hasActionTemplate <…/presentation-template> ;
    gen:hasActionTemplateTargetField "event" ;
    gen:hasActionFillQuery <…/get-event-defaults> ;
    gen:hasActionFillQueryTargetField "event" ;          # optional, default "resource"
    gen:hasActionFillQueryMapping "startDate:startDate location:!location" .

• The button carries the bound reference as fill-query / fill-query-mapping; PublishForm runs it when the form opens (cold cache blocks once, warm serves at once) and applies the first row only — these are defaults for single-valued fields, so no __i suffixes.
• col:!field fills and locks the field, as entry actions already can (Locking pre-filled content #678). Blank values are skipped and left unlocked.
• Precedence: fill query → listing values → explicit param_. An action can carry both a fill query and a listing mapping.
• Magic parameters are bound at consumption, on the publishing user's request.
• The fill mappings are kept apart from the listing mappings in View, so their columns are never hidden from the view's own table.

Doc: new section in docs/magic-query-params.md.

Also in here

• Refactor (own commit): the result-action button block existed in four copies; the list, SVG and plain-paragraph builders now call ViewActionMappings.addResultActions. Two divergences resolved toward the shared version (null-guarded param_<target>/context; Space-namespace fallback for the part field); the paragraph builder's dead space field removed.
• Fix: a result action with several listing mappings in one literal was passed raw and split on the first colon by the form ("a:b c:d" → target "b c", nothing filled). Not a regression — the result-action path never got the phase-2 multi-mapping support, and every multi-mapping in docs/queries/ is on an entry action. View.ActionMapping is now the one col:target parser for all three consumers.
• A query the API fails on now costs the pre-fill rather than 500-ing the form.

Compatibility

• Existing views render identically: no fill triples → no fill params; single listing mappings produce the same URL as before; "void" is dropped as before.
• Old Nanodash ignores the new predicates (button without fill) — deploy before publishing views that use them.
• View is persisted in the API cache snapshot with no serialVersionUID, so the first restart after deploy discards the snapshot and starts cold, by design (ApiCachePersistence.load); the per-entry store still serves query responses.

Verified

• Full suite: 1340 tests, 0 failures. New: ViewFillQueryTest, ViewActionMappingsFillQueryTest (incl. the multi-mapping regression), PublishFormQueryFillTest (11 cases), fixture np-fill-query-view.trig.
• Live demo on https://w3id.org/spaces/test/group: view RAqsB5Zk7p…/qa-fill-demo-view, fill query RA1MUappxs…/get-question-defaults, display RAcRiqiS1n…. On a local build, "❓ ask a question…" opens with the question text pre-filled from the space's label (editable) and the evidence pre-filled with the space's definition nanopub and locked (readonly + locked-value).

Follow-up (not in this PR)

The view-creation template needs three optional members for the new predicates so the form can express them; the target-field placeholder must carry no default. Tracked on #690.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LpQe4aJzdBr1epP8XSGYiY

[github-actions]

🎉 This PR is included in version 5.14.0 🎉

The release is available on:

• nanodash-5.14.0
• GitHub release

Your semantic-release bot 📦🚀