Persist sensor scan work with lease/ack delivery semantics

[MahdiHedhli]

Problem

GET /api/v1/sensor/work currently drains Core's in-memory on-demand scan queue. The service retains a fetched result and retries delivery while that process remains alive, but a process crash, host reboot, or forced shutdown after FetchWork and before a successful device-report delivery can still lose the queued request.

This behavior predates the ARP-discovery integration; PR #105 improves stable ordering, in-process retry, partial-response handling, and (CIDR, segment) deduplication, but intentionally does not turn the queue protocol into a durable job system.

Required design

• Give each queued request a stable work ID.
• Persist queued work in Core rather than an in-memory slice.
• Fetch by lease with a bounded expiry, scoped to the authenticated sensor where applicable.
• Acknowledge only after Core fully accepts the corresponding device report.
• Make acknowledgment idempotent.
• Recover expired leases after sensor crash/restart.
• Preserve per-request segment and scan_ports semantics.
• Define behavior for permanent scan errors, operator cancellation, and retry limits without silently dropping work.
• Keep recurring enabled scan targets separate from one-shot queued work.

Acceptance tests

• Crash/cancel after lease but before scan: work becomes available after expiry.
• Scan succeeds but delivery fails/restarts: work is not acknowledged and is retried.
• Full successful delivery + ack removes work exactly once.
• Duplicate ack is harmless.
• Two sensors cannot both own the same live lease.
• Partial (207) device ingestion does not acknowledge work.
• Queue state survives Core restart.

Relationship

Follow-up from the adversarial review of PR #105. This is a reliability improvement, not a prerequisite for the cache-only ARP identity safety fixes in that PR.