Channel Access (ca://) read operation timed out in fast scan

A Bluesky scan (grid_fast_scan) aborted during execution because a Channel Access (ca://) read operation timed out when trying to query the motor position of device sample_stage-y.

ophyd_async timed out attempting to read BL99P-MO-STAGE-02:Y.VAL during a trigger_and_read call within a fly scan step. This caused the status object to fail with TimeoutError('ca://BL99P-MO-STAGE-02:Y.VAL'), throwing a bluesky.utils.FailedStatus exception and bringing the RunEngine back to the idle state.

## Expected Behavior

ophyd_async successfully reads the current position/value of the motor signal BL99P-MO-STAGE-02:Y.VAL via Channel Access within the defined timeout limit, allowing the fly scan (grid_fast_scan) to continue collecting data smoothly.

## Context & Environment

Scan Type: Fast grid scan (sm_bluesky.common.plans.grid_scan.grid_fast_scan)

Failing Component/Signal: sample_stage-y -> ca://BL99P-MO-STAGE-02:Y.VAL

Frameworks/Tools: Bluesky, Blueapi, Ophyd-Async, aioca (EPICS Channel Access)

Python Version: 3.11.15 (Linux x86_64)

## Steps To Reproduce

Run a fast scan with low speed e.g. speed < 0.4ms

Acceptance Criteria
[ ] Identify and resolve the root cause of the PV timeout.
[ ] The plan grid_fast_scan can read sample_stage-y reliably without throwing a TimeoutError.

Start by reproducing the timeout in sm_bluesky.common.plans.grid_scan.grid_fast_scan with a low speed, focusing on the trigger_and_read of sample_stage-y and PV BL99P-MO-STAGE-02:Y.VAL. Trace the Bluesky, Blueapi, ophyd_async, and aioca status path to identify the root cause; done means the fast scan reads the signal reliably without TimeoutError.

Written by the indexing model from the issue text.