Bound upload bursts and align batching config with the other platform SDKs

[Fiona2016]

Why

Event uploads share the uplink with the app's own requests. On a narrow
connection that competition is measurable, and two properties of the drain loop
decided how much it hurt — neither reachable from configuration:

• The batch roll window was a fixed constant (MAX_BATCH_AGE_MS), so events
  could not be packed into fewer, better-compressed requests.
• The drain loop had no bound at all: a successful upload called
  scheduleNext(0) and immediately claimed the next batch, so a backlog built up
  while offline was emptied in one uninterrupted burst.

Separately, HarmonyOS was the only platform expressing upload pacing as a
millisecond setter. Android, iOS, and Flutter all use the same three enums with
identical case names and values, so tuning advice had to be hand-translated for
this SDK alone.

What

Adopt the shared vocabulary and drop setBatchUploadFrequencyMs:

Setting	Cases	Default
setUploadFrequency	FREQUENT 500 ms · AVERAGE 2 s · RARE 5 s	AVERAGE
setBatchSize	SMALL 3 s · MEDIUM 10 s · LARGE 35 s	MEDIUM
setBatchProcessingLevel	LOW 1 · MEDIUM 20 · HIGH 100 batches/cycle	MEDIUM

Values and defaults match Android's DEFAULT_CORE_CONFIG exactly, so the same
setting produces the same behaviour on every platform. A test pins the enum
values against the other SDKs — silent drift there would invalidate
cross-platform tuning advice without failing anything else.

BREAKING CHANGE

setBatchUploadFrequencyMs is removed. Replace with
setUploadFrequency(UploadFrequency.RARE) to keep the previous 5 s behaviour, or
drop the call to take the new AVERAGE default. Customer-facing docs reference
it in 6 places and are updated with the release.

Notes for review

The per-cycle bound is enforced at every scheduling path, not just the timer.
triggerNow() re-enters the drain directly on each force-flushed error or crash
write and on backgrounding. A scheduler that paced only its own timer would drop
the bound under exactly the load that needs it — an error storm. A cycle that
spends its budget records cycleYieldUntilMs, and both triggerNow() and the
coalesced-retrigger path in drainOnce() floor their delay at it. The first
force-flush of a cycle with budget left is still immediate.

Deferred-upload pipeline fix. It built its FilePersistenceStrategy without
a batch window, so it used the module fallback rather than the configured one.
The cross-process claim guard is derived from that window: with the main process
on BatchSize.LARGE, the deferred process would have considered a batch
claimable while the main process was still appending to it. Both pipelines now
take the configured value, and the module fallback is defined as
BatchSize.MEDIUM so an omitted argument cannot silently change behaviour.

Range clamping is gone — an enum cannot carry an out-of-range value, so the
checks the millisecond setters needed had nothing left to guard.

flushForWork is deliberately left unbounded — the system already scheduled
that drain off the critical path under the app's chosen network/charging
constraints, so bursting there is free.

Verification

• node scripts/unit-node/run.mjs — 143 passed, 0 failed (checked across
  repeated runs; the cycle tests are timer-based).
• ./scripts/ci-check.sh — ALL CHECKS PASSED (HAR build, demo HAP build, ArkTS
  unit-test type check).
• UploadThrottle.test.ets covers: enum values against the other platforms,
  defaults against Android's, the roll window driving the drain decision, the
  per-cycle bound, a control where the budget exceeds the backlog, and a
  force-flush pump that must not buy extra batches within a spent cycle.
• Not verified on a physical device: the pacing behaviour is unit-tested against
  fakes, not measured against real uplink contention.