Per the component-model spec (CanonicalABI.md), `subtask.cancel` on a
subtask that has already resolved collects the pending event and
returns `RETURNED`.  A subsequent `subtask.drop` is valid because
`resolve_delivered` is true at that point.

In the implementation, when an async-lowered host function's future
completes, a `WorkerFunction` (on_complete) is scheduled via the
high-priority work queue to lower the result and deliver the
`Returned` event.  Between the future completing and on_complete
running, another work item in the same batch (e.g. a `ResumeFiber`
delivering a different subtask's event) may allow the guest to
`subtask.cancel` + `subtask.drop` this task, removing it from the
table.  When on_complete then runs, it tries to look up the deleted
task's scope via `call_context`, causing a `NotPresent` panic in
`validate_scope_exit`.

Guard on_complete by checking whether the task still exists in the
table and whether its `join_handle` is still present (taken by
`subtask.cancel`).  In either case, the guest already observed the
resolution and `cancel_scope` released any outstanding borrows, so
on_complete is a no-op.

A new test (`cancel_completed_host_task_does_not_crash`) exercises
the race deterministically: two async host functions that yield once
then complete; the guest waits for the first, then cancels the second
whose on_complete is still queued.

The previous guard checked `join_handle.is_none()` or table lookup
failure, but this doesn't catch the case where a cancelled+dropped
host task's table slot is reused by a new host task before the stale
on_complete runs. The new entry has `join_handle = Some`, so the
guard passes and the stale closure steals the new task's join_handle,
writes to the wrong retptr, and fires a spurious Returned event.

Add a monotonic `epoch` field to HostTask, incremented for each new
host task. The on_complete closure captures the epoch at creation
time and compares it against the current occupant's epoch. If they
differ, the slot was reused and the closure bails out.

Add a regression test that deterministically reproduces the slot
reuse scenario using FuturesUnordered LIFO polling order.