fix(db): adapt /api/storage onto existdb-openapi db-core (held)

[joewiz]

[This PR was co-authored with Claude Code. -Joe]

Summary

Rewrites modules/api/db.xqm as a thin adapter over existdb-openapi's roaster-independent db-core module. All resource CRUD and naming correctness is delegated in-process to db-core (imported by namespace — no HTTP hop, no re-auth; db-core runs as the request user), making existdb-openapi the single audited implementation of db resource handling. eXide stops carrying its own xmldb:store / doc() / encode logic.

The /api/storage surface and eXide's response shapes are unchanged, so the frontend is untouched.

Status — draft, held per the migration plan

This is intentionally a draft:

• It imports http://exist-db.org/api/db-core, a public module that does not yet exist on openapi's develop. It is introduced by the db-core consolidation stack, still under review: existdb-openapi#55 (extracts db-core and registers it as a public XQuery module) and existdb-openapi#59 (the consolidated, binary-safe get-resource shape this adapter consumes — { path, binary, content, mime-type }, no meta=full, no runPath). Against the published openapi the import does not resolve, so CI is red until Missing Error for invalid logins  #55 and Allow saving of empty binary docs #59 land on openapi develop and eXide's openapi dependency floor is bumped to that release.
• The cutover is held: adopting this adapter is also the resource-naming convention flip (eXide's full-encode it%27s.xml → db-core's fn:iri-to-uri form it's.xml), gated on the resource-naming contract decision ([bugfix] Speak decoded UTF-8 resource names on the wire existdb-openapi#54).

Before un-drafting: (1) eXist-db/existdb-openapi#55 and eXist-db/existdb-openapi#59 merged; (2) bump the http://exist-db.org/pkg/openapi dependency semver-min in expath-pkg.xml to the db-core-registering release; (3) resource-naming convention decision (eXist-db/existdb-openapi#54).

What changed

• GET browse → dbc:list, remapped to eXide's envelope/items (mode→permissions, children→items, type→isCollection, modified→lastModified, mime-type→mime); db-core does pagination and per-item writable.
• GET load (XML, non-download) → dbc:get-resource for serialized content (serialization params translated, omit-xml-decl→omit-xml-declaration) plus dbc:properties for owner/group/mode/last-modified. The consolidated db-core's get-resource returns just { path, binary, content, mime-type } (no meta=full, no runPath), so metadata comes from dbc:properties and externalPath is computed eXide's context-path-aware way.
• Binary load + ?download raw streaming stay eXide-side until db-core gains real binary transport (existdb-openapi#38), streamed via response:stream-binary to avoid double-escaping.
• PUT / POST (create|copy|move|rename) / DELETE / PATCH → the matching db-core calls, remapped to { status: "ok"[, path] }. DELETE passes force=true (eXide's recursive semantics); db-core's protected-path guard (403) and copy/move overwrite guard (409) now apply. PATCH errors are classified by db-core (chmod/chown/chgrp → 403, set-mime → 400).
• Drops the dead config: / dbutil: imports and the unused filter query param (declared and handled but never sent by the frontend).

Testing

Adds cypress/e2e/db_resource_adapter_spec.cy.js (9 tests) guarding the adapter paths the broader suite leaves unasserted: the metadata re-sourced from dbc:properties (both the db:load envelope and the properties dialog that consumes it), serialization params driven through a load, ?download for XML and binary, db:patch Apply, and resource-level delete.

These were mutation-verified: reverting db:load to read metadata from get-resource (the regression the consolidated contract would introduce if mishandled) fails the envelope/properties/patch assertions while serialization/download/store/delete stay green — so the guard demonstrably guards.

Verified on a disposable eXist bed running the consolidated existdb-openapi (0.9.7, from existdb-openapi#59) + roaster 1.12.0 + this build: the 9 new tests plus the genuinely adapter-relevant existing specs (file_save, dbmanager, binary_preview) are green (44/44), and the JS unit suite is 179/179.