fix(deps): pin hono to 4.13.3 and nanoid to 3.3.18

[d-cryptic]

Clears all 29 Oneleet dependency-scanning findings on this repo — and 4 more the scanner did not surface.

Opened from a fork: d-cryptic has no push access on respanai/respan (branch-ref creation 404s, permissions.push = false). Happy to move this to a topic branch on the main repo if someone grants access.

Changes

Path	Package	From	To
javascript-sdks/	hono	4.12.9 and 4.12.30	4.13.3
javascript-sdks/legacy/respan-exporter-n8n/	nanoid	3.3.8	3.3.18

The scanner under-reported hono

The lockfile held two hono ranges — ^4.11.4 resolving to 4.12.9, and ^4.8.3 resolving to 4.12.30. Only 4.12.9 was flagged, but 4.12.30 carries 4 advisories of its own. A single resolution collapses both to 4.13.3.

Verified against OSV:

hono@4.12.9    -> 27 advisories
hono@4.12.30   ->  4 advisories
hono@4.13.3    ->  0 advisories   CLEAN
nanoid@3.3.8   ->  2 advisories
nanoid@3.3.18  ->  0 advisories   CLEAN

33 advisories closed, against the 29 the scanner reported.

The hono set is mostly cookie handling and routing: setCookie() missing cookie-name validation, sameSite/priority not sanitised (Set-Cookie injection), and app.mount() stripping the mount prefix using an undecoded path, causing incorrect routing. The most severe is CVE-2026-54290 (HIGH 7.1) — CORS middleware reflecting any Origin with credentials when origin defaults to the wildcard.

hono is transitive here (no workspace package declares it directly), so this is a resolutions pin rather than a dependency bump.

nanoid stays on the 3.x line

nanoid lives in the legacy n8n exporter's own separate yarn.lock, not the main workspace tree — which is why the root resolutions entry (nanoid 6.0.1) never applied to it.

Pinned to 3.3.18, not npm latest. OSV shows the fix was backported to the 3.x line, so the 3.x -> 6.x major jump is unnecessary:

CVE-2026-67213  [{introduced: 0},     {fixed: 3.3.18}]
                [{introduced: 4.0.0}, {fixed: 5.1.6}]

Lockfiles

Both regenerated with yarn 4.9.2 via corepack, --mode=update-lockfile. The diff is 11 insertions / 16 deletions across 4 files — two resolutions entries and the resulting lock changes, nothing else. Collapsing the two hono ranges into one is why the main lock shrinks.

Ref: DEV-11091