Standalone CPAL transport.pos_samples advances by configured period size instead of actual callback sample count

[epifab]

In nih-plug standalone mode with the CPAL backend, transport.pos_samples appears to advance by the configured period_size instead of the actual number of samples delivered to the process callback.

This breaks plugins that schedule events from transport.pos_samples.

On Linux/ALSA, I configured standalone with a period size of 512, but the plugin callback was often invoked with buffer.samples() == 128.

Inside the plugin process callback I logged:

• buffer.samples()
• context.transport().pos_samples()
• delta from previous pos_samples

Example output:

standalone transport: samples=512 reported_pos=Some(0) pos_delta=None fallback_pos=0
standalone transport: samples=128 reported_pos=Some(512) pos_delta=Some(512) fallback_pos=512
standalone transport: samples=128 reported_pos=Some(1024) pos_delta=Some(512) fallback_pos=640
standalone transport: samples=128 reported_pos=Some(1536) pos_delta=Some(512) fallback_pos=1152
...

So the actual processed audio advances by 128 samples per callback, but the reported transport position advances by 512 samples per callback.

## Impact

This causes broken timing in standalone for any plugin that schedules from transport.pos_samples, for example:

- beat/bar synced event scheduling
- sequencers
- rhythm generation
- transport-synced modulation

In my case it produced obviously incorrect rhythmic output.

[epifab]

Maybe a shot in the dark, but shouldn't this line be num_processed_samples += actual_sample_count; ?