fix: flag cache deletion job once all tasks are created (MAPCO-11779)

[almog8k]

Question	Answer
Bug fix	✔
New feature	✖
Breaking change	✖
Deprecations	✖
Documentation	✖
Tests added	✔
Chore	✖

Related issues: MAPCO-11779

Further information:

The cache deletion job is created with its first batch of tiles-deletion tasks (status IN_PROGRESS) and later batches are appended via POST /jobs/:jobId/tasks. Workers start immediately, job-tracker completed the job once the enqueued tasks were done, and the next batch was rejected with 409 (Cannot perform the requested operation on job with final state status: Completed) — the cache was left partially deleted.

Overseer now tells job-tracker when it has finished creating tasks, via raster-shared's CacheDeletionJobParams:

• The job is created with parameters: { ingestionJobId, tasksCreationCompleted }. A job whose tasks all fit in the first batch (always the case for swap-update's single wipe task) is created with the flag already true — no follow-up update.
• Otherwise, after the last batch is enqueued, overseer sets tasksCreationCompleted: true, sending the full parameters object since job-manager's updateJob overwrites parameters rather than merging.
• Completing the job stays job-tracker's responsibility; overseer never completes it.
• If an enqueue or the flag update fails, failPartialJob still marks the job Failed.
• ingestionJobType is no longer sent (not part of the shared schema).
• The creator's input interface is renamed CacheDeletionJobParams → CreateCacheDeletionJobParams to avoid clashing with the shared type.
• Bumps @map-colonies/raster-shared to 9.0.0-alpha.2.

Deployment: pairs with MapColonies/job-tracker#78, which completes the job only once the flag is set. Deploy this first/together.

Known, accepted gap: if every task completes before the flag is written (flag update slow/retried, or overseer crashing in between), the job stays In Progress at 100%. Very unlikely under normal load.