feat: WorkManager parity — task tags, deadlines, InputMerger, UPDATE policy (v3.5.0)

[vietnguyentuan2019]

Implements four Jetpack WorkManager features that had no equivalent here, on both platforms rather than Android-only.

Features

Feature	API
Group cancellation	TaskRequest.tags, enqueue(tags = …), cancelByTag(), cancelByWorkerClass()
Per-task deadline	TaskRequest.deadlineMs, enqueue(deadlineMs = …)
Chain InputMerger	TaskRequest.mergeOutputFromPreviousStep
Periodic update	ExistingPolicy.UPDATE

Deadlines also give TaskTrigger.Windowed.latest real enforcement on iOS for the first time — BGTaskScheduler offers only earliestBeginDate, so latest was previously just a logged warning.

Bugs found while reviewing the in-progress implementation

1. Android InputMerger was entirely non-functional. KEY_MERGE_PREVIOUS_OUTPUT was stamped but never read, and BaseKmpWorker returned Result.success() with no output Data — so a worker's Success.data never reached WorkManager and the default OverwritingInputMerger had nothing to merge. The feature worked on iOS and silently no-opped on Android. Now round-trips through a namespaced KEY_STEP_OUTPUT, with oversized payloads dropped rather than failing a step that actually succeeded.
2. Merge logic was iOS-only — extracted to ChainInputMerger in commonMain so the two engines cannot drift, pinned by commonTest.
3. iOS cancelByTag left the queue inconsistent — deleted a chain's definition without writing the deleted marker, so ChainExecutor would later dequeue the id, find nothing, and log an ERROR for a cancellation the caller had requested. Now writes the tombstone first so the existing cancelled-chain path handles it at INFO.
4. Deadline semantics diverged — Android skipped and continued; iOS returned Failure, aborting the whole chain. Unified on skip-and-continue: an optional stale step must not destroy the steps after it.
5. Operator-precedence bug in a log string dropped a closing paren.
6. tags/deadlineMs were unreachable for standalone tasks — enqueue() had no parameters for them, so cancelByTag could never match a non-chain task.

Deliberate design decisions

• InputMerger is opt-in (false by default). Auto-forwarding would change behaviour for every existing chain and blend data between unrelated steps.
• Tags are validated at construction (non-blank, no commas, ≤100 chars). iOS persists a standalone task's tags as one comma-separated metadata string, so an embedded comma would split a tag and make cancelByTag silently fail to match — the worst failure mode for a cancellation API.
• cancelByTag is not supported for TaskTrigger.Exact on Android (AlarmManager is not tag-indexed). Logs a warning rather than failing silently.
• Deadlines are ignored for periodic tasks on both platforms — a deadline on a recurring task is a delayed cancel, not a deadline. Warned, not silently applied.
• ExistingPolicy.UPDATE degrades to REPLACE for one-time tasks and chains, which have no timer anchor to preserve. The when over ExistingPolicy in iOS enqueueChain is kept exhaustive so adding APPEND later forces a decision there instead of silently falling through to KEEP.

Source compatibility

cancelByTag/cancelByWorkerClass ship with no-op default implementations so existing third-party schedulers and test doubles keep compiling. Classes that override enqueue() must add the two new (defaulted) parameters — 11 mocks in this repo needed that change, which is the evidence the default-impl decision was worth making for downstream users.

Testing

30 new tests (ChainInputMergerTest, TaskTagValidationTest, V350DeadlineAndInputMergerTest), including a regression test proving a worker returning no data never re-emits the previous step's output — on Android the payload physically travels inside the next step's inputData, so echoing input to output would silently corrupt a pipeline.

Verified the suite actually catches the bug: reverting the Android InputMerger fix turns successfulWorker_publishesOutputForTheNextStep red.