monitoring_rules reads any Error::Init as its own setup abort

`bela/examples/monitoring_rules.rs` treats `Error::Init(_)` as proof
that its own `setup` abort happened:

```rust
// `Observe` aborts in `setup`, so a failed init is the expected
// outcome and means the observation was taken.
let observed = match Bela::new(app, &settings) {
Err(Error::Init(_)) => true,
```

and again in `poisoned()`, where `Err(Error::Init(_)) => "failed"` is
what the row asserts the poisoning from.

#166 establishes a second way to get `Error::Init`, before `setup` is
ever called: libbela refuses at the door with `-1` when another process
holds the board. Run the example while anything holds it — a leftover
probe, a project on a board that autoruns one — and `monitoring()`
reports `monitoring=none` as a positive claim that the counters were
off, having observed nothing at all; `poisoned()` reports
`first-init=failed poisoned-new=refused` as if it had demonstrated the
poisoning it exists to assert.

`bela/examples/init_failure.rs` was corrected for exactly this shape in
#166. This one was not, and it is the example `scripts/smoke-test.sh`
drives, so a false row there reads as a passing check.

The distinguishing information is in the error: `-1` is the refusal,
and a `setup` abort is `1`. Reporting the code, or matching on it, would
close it. Note the smoke test matches the exact string
`first-init=failed poisoned-new=refused` (`scripts/smoke-test.sh:818`)
and parses `rules: monitoring=`, so whatever is done has to leave the
contended case falling outside those rather than silently inside them.

Start with bela/examples/monitoring_rules.rs and compare its Error::Init handling with bela/examples/init_failure.rs, especially in monitoring() and poisoned(). Run scripts/smoke-test.sh and verify that the -1 board-refusal case falls outside the positive monitoring and poisoning rows, while setup abort code 1 still produces the expected results and exact smoke-test strings remain valid.

Vom Indexierungsmodell aus dem Issue-Text verfasst.