Keep in-flight async future results alive on drop

[fallintoplace]

Partially addresses #99.

This keeps the owned async launch path from dropping an in-flight stored result as soon as the future is dropped after its first poll.

What changed:

• add DeviceFuture::Drop cleanup that synchronizes the assigned stream before releasing a stored in-flight result
• if that cleanup cannot prove the stream is idle, log the cleanup failure and leak the stored result instead of risking an early drop
• add small unit tests around cleanup ordering and the sync-failure behavior
• document the blocking drop behavior in the cuda-async README

Why:

• OwnedAsyncKernelLaunch::execute moves owned resources into DeviceFuture::result while the future is still pending
• dropping that future after submission could then drop those resources while stream work was still in flight
• for DeviceBox, that is especially risky because drop enqueues cuMemFreeAsync on a separate deallocator stream

Tradeoff:

• dropping an in-flight future can now block long enough to synchronize the assigned stream

Scope note:

• this PR is intentionally narrow and only covers the normal drop/cancellation path after first poll
• it does not try to solve the separate "launch succeeded, callback registration failed" path yet