Inconsistent counter naming: `executeCount` (AsyncBatcher, AsyncQueuer) vs `executionCount` (everywhere else)

[manudeli]

Describe the bug

All sync utilities (Batcher, Queuer, Debouncer, Throttler, RateLimiter) and AsyncRetryer expose an executionCount field in their state, but AsyncBatcherState and AsyncQueuerState alone call the same concept executeCount:

State interface	Field name
BatcherState, QueuerState, DebouncerState, ThrottlerState, RateLimiterState	executionCount
AsyncRetryerState	executionCount
AsyncBatcherState, AsyncQueuerState	executeCount ← inconsistent

This looks like an accidental divergence introduced in #54 (where the field was first added) rather than a deliberate distinction. Grammatically executionCount ("number of executions") is also the natural noun compound, consistent with the related maybeExecuteCount fields which are named after the maybeExecute method.

One could argue executeCount was meant to be distinct because it increments at execution start (and doubles as the key for the internal asyncRetryers map / getAbortSignal()), while the sync executionCount increments after completion. However, AsyncRetryerState.executionCount also increments at execution start yet uses the executionCount name — so the async utilities are inconsistent even among themselves, which suggests accidental divergence. If maintainers do consider the start/completion distinction meaningful, it would be worth documenting explicitly instead — either way the current state is confusing.

Proposal

Rename executeCount → executionCount in AsyncBatcherState and AsyncQueuerState (pure rename, no behavior change). Since Pacer is pre-1.0, this could ship as a minor with a changelog note calling out the rename.

Affected:

• packages/pacer/src/async-batcher.ts (state field, getAbortSignal(executeCount?) parameter, internals)
• packages/pacer/src/async-queuer.ts (same)
• Framework guide docs referencing executeCount (async-batching / async-queuing guides for react, preact, solid, angular, vanilla)

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliably reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.