Worker can remain "running" with a stale runner and stop processing work

## Versions

- `@convex-dev/workpool`: 0.4.9
- `@convex-dev/batch-worker`: 0.2.0
- `@convex-dev/workflow`: 0.3.12

## Problem

After upgrading Workpool from 0.4.7 to 0.4.9, workflow jobs stopped processing.

The Batch Worker status was `running`, but its runner, monitor, and `lastWorkTs` were stale. New jobs accumulated in `pendingStart`.

Twenty waiting jobs processed immediately after we rolled back to Workpool 0.4.7.

## Suspected cause

`ping()` returns when the stored status is `running`. It does not check whether the stored runner is still active.

The monitor was also stale, so it did not recover the worker.

## Expected behavior

`ping()` should restart the worker when the status is `running` but its runner is missing or stale.

## Workaround

Roll back to Workpool 0.4.7, or run `kick:forceKick` after deploying 0.4.9.

Start by tracing the `ping()` entry point and the `kick:forceKick` workaround, then inspect how the stored status, runner, monitor, and `lastWorkTs` are checked. Reproduce the running-but-stale condition if possible. Done means `ping()` restarts a worker whose runner is missing or stale, while healthy running workers continue normally.

Written by the indexing model from the issue text.