The context accessors assume interleaved buffers and nothing checks it

Every accessor on `BlockContext` and `RenderContext` computes `frame * channels + channel`, and says so: `context.rs:312` — "the accessors mirror the C helpers from `Bela.h` / `Utilities.h` and assume the default interleaved buffer layout". Two unit tests pin that arithmetic (`context.rs:1676`, `:1700`).

Nothing checks that the assumption holds.

`BelaInitSettings` has an `interleave` field. `Settings` does not write it (`settings.rs`, `apply_to` writes 15 fields and that is not one of them), so it is left at whatever `Bela_defaultSettings()` returns — which on a board has already applied the `CL=` line from `~/.bela/belaconfig`. `BelaContext` then carries the answer in `flags`, as `BELA_FLAG_INTERLEAVED`, and no accessor here reads it: `flags` has no accessor at all, and the string `INTERLEAVED` appears nowhere in `bela/src`.

So a configuration this crate cannot request, and does not expose, can still arrive — and if it does, every `audio_read`, `analog_read`, `audio_write` and `analog_write` silently addresses the wrong sample. No panic, no error, no warning: a program that runs and sounds wrong.

Bela's own answer to the layout is the `NI` accessors — `audioReadNI`, `audioWriteNI`, `analogReadNI`, `analogWriteNI`, `analogWriteOnceNI` (there are no `NI` variants for the digital or `pinMode` helpers). They are `static inline`, so like their interleaved siblings they could only ever be rewritten in Rust rather than bound; the crate has rewritten one layout and not the other.

## What would close this

One of these, and which one is the question:

1. **Refuse it.** `validate_settings` already sees a `ResolvedSettings` before the audio system is built and can decline; a non-interleaved configuration could be `Error::SettingsRefused` with the process untouched. Cheapest, and honest about what the accessors do. Needs `interleave` reachable from `ResolvedSettings`, which it is not today.
2. **Assert it.** Check `BELA_FLAG_INTERLEAVED` in `setup` and refuse there — except that `setup` runs inside `Bela_initAudio` with the hardware up, and refusing from there leaves the process unable to build another audio system, which is the reason `validate_settings` exists.
3. **Support it.** Rewrite the `NI` accessors too and pick the layout per block. The most work by far, for a configuration nobody has asked for.

(1) looks right, with `Settings::interleave` added so a program can also state what it wants rather than only find out.

## What is not known

Whether a Bela Gem can be put into a non-interleaved configuration at all, and what `Bela_defaultSettings()` returns for `interleave` on the shipped image. `docs/board-facts.md` does not record it. That is a five-minute measurement on the board and it decides how much this matters — if the field is ignored on this hardware, the answer may be a documented note rather than code.

Recorded in `docs/scope.md` as one of the `BelaInitSettings` fields the crate does not expose; this issue is the correctness half of that entry.

Start by measuring the value of interleave returned by Bela_defaultSettings() on the board, then read settings.rs, validate_settings, ResolvedSettings, and the BlockContext/RenderContext accessors in context.rs. Compare the result with docs/board-facts.md and docs/scope.md. Done means the project has a decided, tested response to non-interleaved layouts and documents the supported behavior.

Vom Indexierungsmodell aus dem Issue-Text verfasst.