fix: read the part view-displays query from its view, not a constant

[tkuhn]

Part of #664.

AboutPartPanel ran QueryApiAccess.LIST_PART_VIEW_DISPLAYS (RAKHyaoB…) while the part view nanopub declared RA74rCoU… — two separate live heads, the constant having been left behind by the 2026-08-20 federation rebase. The space, user and maintained-resource panels all take the query off the view; the part panel now does the same, and the drifted constant is removed.

Why it matters beyond tidiness

The drift is silent, and it gets worse as views gain per-row actions. An action maps query result columns into a pre-filled publish form, so a panel running an older query version than its view declares renders no button at all — no error, no log line. That is exactly what would have happened to the new ♻️ override... action of #664, whose mapping columns only exist in the version the view points at.

Context: the nanopub side of #664

Already published live, no code change needed for them (the view constants are chain anchors, View.get follows supersedes):

	query	view
space	RAGnECNo…/list-view-displays-space	RA3G86T6…/view-displays-view
user	RAzaL0ej…/list-view-displays	RAtVGHYy…/view-displays-view
maintained resource	RAKFhW1T…/list-view-displays	RAM3xp8U…/view-displays-view
part	RAsdgRZ1…/list-part-view-displays	RA7eYpQF…/part-view-displays-view

Each view-displays table now offers exactly one ♻️ override... per row, selected in SPARQL rather than in code: a standalone display reopens its own nanopub in override fill mode, while a preset-borne row (whose source nanopub is the preset assignment, not a display) instead opens the add-view-display form pre-filled with its view, publishing a standalone display that wins latest-wins over the preset-supplied one. The two mapping columns are exact complements, so the shared label can never double up.

Presets and roles were deliberately left out of #664: a preset assignment is a (preset, resource) pair and a role attachment is a single gen:hasRole triple, so deactivate/detach already covers them. (Both would also have needed more than a view change to work at all — Preset.get resolves latest only through the supersedes chain, and role IRIs are npx:embeds-ed so they are re-minted on every new version.)

Testing

• Compiles.
• All four published queries verified against the live API: results byte-identical to the previous heads on every pre-existing column, and zero rows with both or neither override column set.
• No measurable performance change (interleaved timings, deltas within run-to-run noise): space 2.01s → 2.02s, user 2.44s → 2.36s, maintained resource 0.57s → 0.60s, part 0.66s → 0.66s.
• Not yet exercised: the override publish form round-trip itself.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LqfrG3VXH5tzWXPvYJzXML