feat: bidirectional device sync with success banners

[inkpot-monkey]

A note first

Thank you for this project. I found it while looking for a self-hosted alternative to
the Supernote cloud, and the work you've put into the parser, client, and server is
genuinely excellent. When I tried to use it with my own Supernote device, though, I hit
one gap: bidirectional sync between the device and the self-hosted server wasn't
working — a device sync threw failure banners and didn't reliably round-trip. This PR
fixes that, and it's tested end-to-end against a real Supernote device (a Nomad,
system version 202407).

What this does

Makes a real Supernote device sync cleanly against the self-hosted Private Cloud
server. Before this branch a device sync threw three failure banners ("Private Cloud
Sync Failed", "App Data Sync Failed", digest sync failed) and pulled nothing reliably;
after it, a full sync completes with success banners, repeatable, verified live on a
Supernote Nomad (system version 202407).

The work spans three device-sync subsystems that were previously broken or unregistered.
All of it extends the existing shared store and services — the device is never
forked onto its own code path, so the CLI planner and web flows keep working unchanged.

Subsystems

1. File-pull healing (device pulls notes down)

The device presents category-container children (NOTE/Note, DOCUMENT/Document) as
if they lived at the root. Reads un-flattened this, but path-based writes did not,
so an upload to Note/… created a rogue root Note/ folder the device never scans.
VirtualFileSystem now resolves a leading path segment in the flattened-root namespace
(_resolve_root_segment), container-first, so a fresh upload heals past a rogue folder
with no migration. FileService.upload_finish reports the true storage path.

2. Planner write path (bidirectional task sync)

The device's /api/file/schedule/* write/list endpoints were unregistered (404 →
"Private Cloud Sync Failed"), and its task shape didn't fit the CLI-oriented model
(opaque string taskId, ungrouped, links/isDeleted/lastModified/*sort*,
upsert-by-id).

• t_schedule_task gains device_task_id (+ unique index on (user_id, device_task_id);
  NULL for CLI rows, so the constraint binds device rows only), nullable task_list_id,
  is_deleted tombstone, device-clock last_modified, and the sort family — one
  non-destructive Alembic migration (SQLite batch rebuild).
• ScheduleService.upsert_task / upsert_tasks add the device write seam (upsert on
  (user_id, device_task_id), atomic batch, soft-delete = absence on next sync); the
  CLI's insert-only create_task is untouched.
• Spec routes POST /api/file/schedule/task, PUT …/task/list, POST …/{group,task}/all
  reuse the same service and echo the device's own taskId. A single
  DEVICE_TASK_PASSTHROUGH_FIELDS list keeps the DTO→DO→VO passthrough from drifting
  (guarded by a test). The CLI can now also create ungrouped tasks for device parity.
• DELETE /api/file/delete/summary is accepted alongside POST (the device sends DELETE
  per the OpenAPI spec; both verbs map to the one handler) — clears the digest banner.

3. Realtime channel ("App Data Sync Failed")

The device opens an Engine.IO-v3 / Socket.IO-v2 websocket that fell through to the
MCP/ASGI catch-all and 500'd, aborting the whole sync. realtime.py hand-rolls a
dependency-free EIO3/SIO2 endpoint (modern python-socketio/engineio hard-reject
EIO=3) that connects cleanly and enforces auth on the query-param JWT. Live
validation showed the app-data banner was a downstream symptom of the planner/digest
404s — once the channel connects and the REST calls succeed, app-data sync completes
with no server-initiated events required.

Testing

• Unit/API tests across all three subsystems (round-trip, upsert-not-duplicate,
  tombstone, atomic/skip-malformed batch, CLI↔device coexistence, socket handshake/auth,
  VFS rogue-root healing, migration up + column presence). Full suite green on 3.13/3.14
  (406 passed); ruff + ty clean.
• Live-validated end-to-end on a physical Supernote Nomad (system version 202407):
  task create/edit/complete/delete round-trips and survives reboot; CLI-created tasks
  appear on the device; a real .note pulls down; success banners, repeatable
  (confirmed with the socket.io capture flag both on and off).

Out of scope / known limitations

• No clock-based conflict resolution — last write wins (single-device home use; the
  device push overwrites unconditionally).
• Deletes reflect by absence (tombstone hidden from list), not an echoed tombstone.
• group/all / task/all accept but ignore pagination (documented in the handlers).
• Multi-device concurrency and the server→device file mirror remain out of scope.

[inkpot-monkey]

Follow-up commit: propagate off-device planner-task deletes as tombstones.

While live-testing the planner sync I found one more resurrection gap that the earlier commits didn't cover: a task deleted off the syncing device (via the CLI, the web UI, or another device) came back on the next sync. The device's task/all read hid soft-deleted rows, so the device never learned of the deletion and re-pushed its local copy.

This commit:

• has the device read POST /api/file/schedule/task/all return isDeleted='Y' tombstones (the CLI read GET /api/schedule/tasks stays live-only);
• turns the CLI delete_task into a soft-delete that stamps lastModified/updateTime, so the tombstone out-versions the copy the device holds and wins the last-writer merge;
• registers DELETE /api/file/schedule/task/{id} — the ack the device sends on seeing a tombstone, which previously 404'd and surfaced as "To-do Sync failed" even though the delete had already propagated. The ack purges the tombstone (resolving the id against both the device id and a CLI row's surrogate id), which is what lets the protocol converge: without it the device re-acks the same row on every sync.

Verified end-to-end on a Supernote Nomad (system version 202407): an off-device delete disappears and stays gone with zero sync banners, and after the device's single ack task/all goes empty and stays empty across repeated syncs. The note/PDF file channels already propagate deletes via the folder-list and are untouched. Full test suite green (411 passed).

[allenporter]

Thank you so much for the contribution. Can we tackle the three issues as separate PRs to get them reviewed and submitted faster? Typically best practice is not to send separate unrelated things in a single PR.

For #1 there is more nuance to the device behavior than what the PR descriptions says -- different APIs deal with the device categories differently (e.g. web vs device APIs) so I want to make sure we're describing the fix properly.

Also if you can list out the steps to reproduce the first issue that would be really helpful.