…ank (#475)

* fix: read Keenable page text from snippet, not description

Keenable sends both fields on every result: snippet carries the page text and
description is the page's meta description, which is empty for most pages. The
mapping used `result.description ?? result.snippet`, and since ?? only falls
through null and undefined, the empty description won every time and organic
sources came back with a title, a link and no text.

Reads snippet first now, with description as the fallback. The page text is
whole-page rather than excerpt-sized, so it is whitespace-collapsed and capped
at 500 chars to keep it comparable to the other providers here and out of the
reranker's and the LLM output budget's way.

The existing test passed because its fixture had a populated description and no
snippet, a shape the API never returns; it now uses the real one.

* fix: pick the snippet on emptiness, not nullishness

The new toSnippet still chained with ??, so a result carrying `snippet: ''`
alongside a populated description kept the empty string: the same failure the
commit set out to fix, only with the two fields swapped.

Both fields are now defaulted to '' and the pick is an explicit emptiness
check, which also clears the strict-boolean-expressions warning a || chain
raises here. Covered by a test that fails on the ?? version.

* chore: restore package-lock.json to the base version

The lockfile was rewritten by a local npm install on macOS, which dropped the
`libc` selector from 16 optional native binding entries. On a Linux `npm ci`
that makes both the glibc and musl variants eligible whenever cpu and os
match, so the wrong binding can be installed. The fix in this PR is
source-only, so the lockfile is back to what the base has.

---------

Co-authored-by: Ilya Bogin <ilya.bogin@keenable.ai>