[Feature] Visual page reordering for Organize PDF

[ChrisCreatesNet]

Problem or use case

When I want to move page 7 of a 10-page scan to the front, I can't do it visually. Organize PDF only accepts a typed qpdf spec, so I have to know the syntax and count pages in my head to arrive at 7,1-6,8-10. I get it wrong on anything longer than a few pages.

A related issue: routes/tools/organize-pdf.ts caps order at 200 characters via rangeField, So a per-page list stops fitting around page 50, so there are some roadblocks on longer documents.

Proposed solution

With a single PDF loaded, show page thumbnails in the main pane and let me drag them into the order I want. The settings panel keeps showing the spec that will be submitted, so the existing syntax stays visible and nothing becomes magic. Keyboard reordering as well as pointer, to match the a11y work in 2.2.0.

Batches and pipeline steps keep today's text input, since neither has a single document to display.

No backend change needed - the existing organize-pdf route already works. Notes:

• @dnd-kit/core, @dnd-kit/sortable and pdfjs-dist are already dependencies of apps/web, so this needs no new packages.
• The registry already has a ResultsPanel slot for tools that own the main area. The only structural change is letting a document-mode tool override the read-only viewer, much as interactive-split already does.
• To respect the 200-character cap, the grid should emit ranges rather than a flat list. Collapsing consecutive runs turns "one page moved to the front of a 400-page document" into 400,1-399.
• Extract Pages and Remove Pages have the same shape, so the grid could serve them later.

Two questions before anyone writes code:

1. Is per-page delete in scope for a tool called "Organize", or should this stay reorder-only?
2. Four new UI strings across 21 locales is roughly 90 lines on its own, and since every locale is typed against en.ts, an English-only PR fails typecheck. That pushes the change past the 400-line PR cap with no clean split I can see. What's the best way to handle that?

Alternatives considered

• Typing the page order by hand.
• Doing the reorder in pdfarranger or similar and bringing the file back, which defeats the point of having the tool in SnapOtter.
• I prototyped the approach locally against 2.2.0 to confirm the 200-character limit rather than guessing at it. It works, so it's definitely buildable.

Area

Existing tool improvement

Contribution

• I'm willing to submit a PR for this feature

[snapotter-hq]

Green light. I re-checked the three load-bearing claims and they hold: the .max(200) on order is real (organize-pdf.ts:8, and extract-pages and remove-pages each carry their own copy of the same field), dnd-kit core/sortable/utilities and pdfjs-dist are already in apps/web, and the ResultsPanel slot does what you think it does. Emitting collapsed ranges instead of a flat list is the right call.

Reorder only. Remove Pages already owns deletion with its own route and settings, and two tools deleting pages makes the catalog harder to search than it is to use.

On i18n, add the keys to en.ts and leave the other 20 alone. The translation pipeline runs on Claude Code subagents, so it's a maintainer-side step: I'll run pnpm i18n:translate against your branch and push the generated locale files before review. Generated lines aren't review surface and they don't count against the 400, which should put your diff comfortably inside the cap.

Tracked in #1055. The CLA bot will comment on your first PR.

[snapotter-hq]

Shipped in your PR #1249, @ChrisCreatesNet. Closing this discussion as resolved.