[inureyes]

Summary

Gemma 3n VLM stashed its projected per_layer_inputs tensor in a single RefCell<Option<…>> cell that get_input_embeddings wrote and forward_with_embeddings drained via take().unwrap(). The batch scheduler runs embedding-prep at enqueue time but prefill asynchronously, so a burst of concurrent Gemma 3n VLM requests could overwrite the cell before the first prefill consumed it — the first prefill then saw the wrong row's tensor, or panicked on None when the timing flipped. This affects only the batched mlxcel-server path; single-row CLI / bench paths are unaffected.

Fix

Replace the cell with Gemma3nPerLayerInputsState (a per-SequenceId map plus a fallback slot), mirroring the existing Gemma4PerLayerInputsState:

• Override forward_with_embeddings_and_sequence_id on Gemma3nVLModel so prefill resolves from the seq-keyed map first and falls back to the legacy slot for CLI / bench / single-row callers; the legacy forward_with_embeddings routes through it with seq_id = None.
• Wire release_sequence_state_by_id to drain the map alongside the scheduler's per-sequence cache cleanup.
• Add the LoadedModel capability methods (bind / take / install_gemma3n_per_layer_inputs_*) and hook them into drain_incoming_requests and the preemption round trip, next to the Gemma 4 calls.

Testing

• make verify-clippy (--all-targets --features metal,accelerate -- -D warnings) — clean
• make verify-fmt — clean
• New Gemma3nPerLayerInputsState unit tests (burst-enqueue race, fallback round trip, release semantics, preemption round trip) — 8/8 pass (--ignored, serial MLX)

Closes #85