fix(ui): one trail length for the bar, the store and /api/flow (#1976)

[danusha2345]

Fixes #1976.

Problem

Three trail limits disagreed. The trail store saves 64 hops, /api/flow read 24, and the in-memory trail had no limit. Separately, /api/nodes answers 60 ids per request. As a result:

• "Read as flow" failed on any walk of 25 or more hops, including trails the store had just saved.
• resolveTrailNames sent every unnamed hop in one request, so a cold load of a 61–64 hop link never got its names.

Fix

One number, the store's MAX_TRAIL_HOPS = 64:

• /api/flow imports it from trail-store.ts instead of keeping its own 24.
• The trail keeps at most 64 hops. push drops the oldest, and hydrate keeps the last 64 of a longer link. So anything on the bar can be saved and read as a flow. The ui package can't import server code, so the constant is repeated there with a comment pointing at the store.
• fetchNodeRefs sends ids in batches of 60 and merges items and missing. A request of 60 or fewer is still a single call.

Tests

• ui-flow-api.test.ts: a 64-hop trail returns 200, and 65 hops is refused naming the 64 cap.
• ui-package.test.ts: 70 pushes leave the last 64 hops, and 64 unnamed hops resolve in batches of 60 and 4 with every name filled in.

All three fail on main. svelte-check reports no errors.

Full suite on this branch (Linux, Node 22, native kernel): all tests pass except the known intermittent extraction.test.ts pool-worker crash from #1779 (V8 Fatal process out of memory: Zone, fixed by #1883), which also occurs on main.

🤖 Generated with Claude Code

[colbymchenry]

Thanks @danusha2345! Your commits here were carried into #2001 (authorship preserved), with a few follow-up changes from review, and that is now merged. Closing this one in favour of it. It will be in the next release.