fix: don't assign NaN ids to XBEL items missing an @id attribute

[Matovidlo]

Fixes #2322

Summary

XbelSerializer._parseFolder parsed an item's id with plain parseInt(node[':@']['@_id']). When the @id attribute is missing or non-numeric, parseInt(undefined) is NaN, which later gets serialized back to disk as the literal string id="NaN".

NaN !== NaN, so any subsequent sync round can never match that item back to itself by id — it looks "new" every time. Reproduced end-to-end in an isolated WebDAV test setup: a folder with no @id got triplicated across sync cycles, and the resulting spurious delete+create diff tripped the "would delete N% of your local links" failsafe (40% in the small repro; up to 100% observed in the wild on a bigger tree).

Fix

When an item's @id doesn't parse to a real number, assign it a fresh, unique negative id instead of NaN. Negative ids can never collide with the real, ever-incrementing positive ids handed out elsewhere (CachingAdapter.highestId starts at 0 and only increments), and — unlike NaN — they're stable: once assigned and written back, re-parsing that same id on the next sync yields the same value again, so identity matching stays consistent.

Testing

The project's own test suite (npm test) runs via Selenium against a real browser build, which I couldn't execute in my sandbox. Instead I compiled src/lib/serializers/Xbel.ts in isolation with tsc and wrote a standalone round-trip check against the compiled, unmodified module:

• Parse an XBEL folder/bookmark with no @id → before the fix: ids are NaN. After the fix: real, distinct negative ids.
• Re-serialize and re-parse (simulating the next sync) → ids stay identical across the round-trip, which is exactly the property that was missing before (previously NaN serialized/re-parsed was still non-self-equal in downstream comparisons).

Also ran eslint and tsc --noEmit against the change — both clean.

I'm happy to also add a proper mocha-based unit test for XbelSerializer in the format you'd prefer for this repo — let me know if there's a preferred location for standalone serializer tests, since I didn't see an existing one to follow as a pattern.