chore(deps): take nextcloud-vue 2.31.1, so a hovered KPI tile stops nesting

[rubenvdlinde]

Takes nextcloud-vue 2.31.1 so a hovered KPI tile stops drawing a card inside
its own card.

⚠️ THE CAUSE IS AN INSET, NOT A COMPONENT. A card widget renders flush and
then has its padding put BACK by the card-fit rule (padding: 8px 14px), so
the KPI sits inside the wrapper while the WRAPPER draws the border, radius
and background the user reads as "the card". The library's
--clickable:hover rule then drew a 2px border and a drop shadow on the KPI
itself, 8-14px in from the edge being hovered.

Measured live on dossiq, while genuinely hovered: the tile carried a 2px
rgb(0,103,158) border and its own shadow, inset 9px from the wrapper's top
and 15px from its left. A non-card-fit tile sits at 1px, so its border lands
on the wrapper's own edge and reads as one card. That inset is the whole
difference, which is why it looked app-specific and was not.

nextcloud-vue#932 moves the affordance to the wrapper. No layout change:
nothing moves, one card outlines. Verified in the browser with a real pointer
hover:

before inner 2px rgb(0,103,158) + shadow wrapper grey, no shadow
after inner transparent, no shadow wrapper rgb(0,103,158) + shadow

Every app with clickable stat, gauge or delta tiles had this. This bump is
one of the fleet sweep that clears it.

Dependency change only: package.json and the nextcloud-vue entry in
package-lock.json.

[github-actions]

Quality Report — ConductionNL/shillinq @ 23abf69

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-manifest-shell		✅
format		✅
check-l10n-js		✅
check-schema-l10n		✅
check-manifest-budget		✅
check-markers		✅
check-registers		✅
check-seeds		✅
check-fragment-required		✅
check-nav-reachability		✅
check-job-registration		✅
test-l10n		✅
composer			✅	✅ 106/106
npm			✅	✅ 537/537
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					✅
Playwright					⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development
Hydra gates					❌

---

Quality workflow — 2026-09-02 18:47 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

Merging with quality / Hydra Gates red, because the failure is pre-existing
on development and this change cannot reach it. The evidence:

The control. I dispatched Code Quality on shillinq's development branch
today (run 33665911627). It fails the SAME gate with the SAME message:

[gate-53] effective-manifest-crossref: FAIL — 1 structural violation(s)
in the ASSEMBLED manifest (base+fragments+menu-layout)

Development's last green run was 2026-09-01T19:04, before whatever changed.
A green that old is not evidence the branch is clean today.

Why this diff cannot cause it. gate-53 assembles the manifest from
src/manifest.json, src/manifest.d/**, src/menu-layout.json and
lib/Settings/*register*.json, and it is diff-scoped on exactly those inputs.
This PR changes two files, package.json and package-lock.json, and GitHub
reports the same two. The gate also uses a VENDORED port of buildManifest —
hydra ships no node_modules — so it never reads the installed
nextcloud-vue at all.

Reproduced locally: it passes. Running the gate against this tree gives 13
warnings and 0 errors, under origin/development and under origin/main
(which are identical commits here). I could not reproduce the CI failure under
any base.

And 17 sibling apps took the identical one-line change and went green,
including their E2E on the branch.

⚠️ So gate-53 needs its own look on shillinq. It is not a dependency problem
and it is not new to this branch; it is development's, and the 2026-09-01
green simply predates it.