fix: bump Node to 22 for logseq nightly engines requirement

[liby]

Problem

Builds using version: nightly (and any current logseq frontend commit) fail with:

error logseq@0.0.1: The engine "node" is incompatible with this module. Expected version ">=22.20.0". Got "20.20.2"
error Found incompatible module.
##[error]Process completed with exit code 1.

Example failing run: https://github.com/liby/liby/actions/runs/24714459918

Root cause

logseq/logseq package.json now declares engines.node": ">=22.20.0", but this action pins node-version: '20' in action.yml (introduced by 394c988 to keep compatibility with then-current nbb-logseq).

Why Node 22 is safe now

nbb-logseq 1.2.173 (the version pinned here via bb: 1.2.174 / related deps) already has engines.node": ">=20.10.0" in its package.json, so moving to 22 does not regress the concern that motivated #46's revert.

Why explicit '22' instead of 'lts/*'

lts/* auto-rolls when a new Node major becomes LTS, which is exactly what burned #46 last time. Pinning to '22' keeps the upgrade intentional.

Change

Single line in action.yml: node-version: '20' → '22'.

[logseq-cldwalker]

Hi. This repo doesn't support DB graphs yet and we don't have bandwidth to add that support. I'm closing this because this contribution incorrectly assumes that DB graph support exists by referring to https://github.com/logseq/logseq which is now DB graph only. I've added this note to be more explicit about this repository's current state

[liby]

Thanks for the response. To clarify the scope of this PR: it does not assume or attempt to add DB graph support — it's a pure Node engine bump.

Two reasons it's worth considering independent of DB graph plans:

1. Node 20 reached end of active LTS on 2026-04-30. Pinning the action to '20' will become a maintenance liability soon regardless of which logseq versions are supported.

2. The bump is a no-op for file graph users. Logseq 0.10.15 (and earlier) has no engines.node constraint, so Node 22 builds them fine.

If the project's stance is that version: nightly should not be used at all, that seems orthogonal and could be enforced more explicitly (README warning, or a runtime check in the action).