fix: bulk_edit_raindrops update/move/remove all 404 on wrong path param key

[sebWarembourg]

Summary

bulk_edit_raindrops fails 100% of the time on all three operations (update, move, remove). Found this while running a real batch (54 bookmarks) through an MCP client.

Root cause

batchUpdateBookmarksInCollection and batchDeleteBookmarksInCollection call PUT/DELETE /raindrops/{collectionId} but pass params.path.id instead of params.path.collectionId:

const { data } = await this.client.PUT("/raindrops/{collectionId}", {
  params: { path: { id: collectionId } as any },
  body: updates,
});

openapi-fetch substitutes path tokens by exact key match against the literal {token} in the path string you pass at the call site. Since the string says {collectionId} and the key supplied is id, no substitution happens — the request goes out with the literal, unsubstituted {collectionId} segment and Raindrop's API 404s on it. (The generated type for this operation is misleadingly named { id: number }, which is presumably how the id key crept in — but the runtime template only cares about the string literal, so it still needs as any to satisfy the type.)

batchUpdateBookmarks (used for operation: "move") has a related but separate bug: it calls PUT /raindrops with no collection segment at all, which isn't a valid Raindrop endpoint — 404 as well.

Separately, bookmark_manage's single-item update handler accepts collectionId in its input schema but never reads it when building the update payload, so it can tag a bookmark but never move it between collections.

Fix

• Fix the path param key to collectionId in both batch methods.
• Give batchUpdateBookmarks an optional collectionId param (defaults to 0, i.e. all collections) and route it through /raindrops/{collectionId} like the other batch methods; pass the tool's args.collectionId through from bulk_edit_raindrops's move handler.
• Map bookmark_manage's collectionId onto collection: { $id } in the single-item update payload.

Testing

• tsc --noEmit and bun run build pass.
• bun run test: same 8 pre-existing failures on this branch as on unmodified master (all due to missing RAINDROP_ACCESS_TOKEN/live-API tests in this sandbox, unrelated to this change) — no regressions.
• Verified against the live Raindrop API by replaying the exact fixed request shapes with curl against a real account/collection: update (tag), move, and remove all return 200 with the expected result/matched/modified after the fix; the pre-fix shapes reproducibly 404 on the same account.