v1.4.1 — fix --from-local on Evernote v11 + auto-detect

Bug fixes (supersedes v1.4.0)

v1.4.0's --from-local mode shipped two bugs that surfaced on first real test against an actual Evernote v11 install. Anyone on v1.4.0 should upgrade.

1. Auto-detect didn't find the cache file. findSqlInDir() only checked direct children of conduit-storage/, but real installs put the SQL files one level deeper inside a per-host subfolder (https%3A%2F%2Fwww.evernote.com). Now recurses one level.

2. Evernote v11 produced cryptic errors instead of clear guidance. v11 (released 2026-01-19) replaced the v10 TKey/TValue JSON-blob shape with flat columns and dropped CacheLookaside entirely. Bodies are stored as plain text only — the HTML/ENML this importer needs is fetched on-demand and not cached locally. v1.4.1 detects v11 at runtime and refuses with:

   Evernote v11 desktop cache detected — --from-local does not support v11.
   Use --batch with an ENEX export instead.

   …instead of Unexpected Nodes_Note schema (no recognised id/value columns) which left users stuck.

Updated guidance

--from-local is v10-only. README's "Which mode should I use?" decision tree now flags this explicitly. v11 users must use --batch <enex-folder> with an ENEX export — that path is unaffected and works on every Evernote tier.

Compatibility

• Same flags, same exit codes, same progress.json format as v1.4.0
• Test suite: 558 pass / 0 fail / 7 skipped (added 2 regression tests)
• --batch mode is unchanged

Install / upgrade

npm install -g evernote-to-onenote@1.4.1

🤖 Caught by post-publish testing on a real Evernote v11 install. Plan #47's pre-implementation BLOCKERS B1/B2 (verify schema before coding) had explicitly called this out — v1.4.1 closes the gap.