probe-init-failure.sh: the busy probe's holder is the one remote process nothing bounds

`scripts/probe-init-failure.sh:319` starts the `busy` probe's holder
detached:

```sh
remote "cd $REMOTE_DIR && nohup ./init_failure render-check $HOLD_SECONDS \
> holder.log 2>&1 & echo started" > /dev/null
```

Every other remote launch in `scripts/` goes through
`timeout -s INT -k 5`, and the script's own remote half says why:
"Bounded, because a probe that hangs holds the audio device and every
later run would fail for that reason instead of the one being
measured." The holder is the exception. In the ordinary case it ends
itself after `HOLD_SECONDS`, which is what the argument asks for; what
is unbounded is a holder that hangs inside libbela — in a script whose
subject is audio systems that do not come up.

What it costs, as far as anyone knows: interrupting during the `busy`
probe, or losing the ssh just after the holder starts, leaves a process
on the audio device for up to `HOLD_SECONDS` while `restore()` runs its
`systemctl start bela_daemon` beside it. Whether that does any harm is
not known — this board does not refuse a second process ("Audio
thread", `docs/board-facts.md`), so the daemon may simply start.

Not a regression from #163. That change removed a
`pkill -9 -x init_failure` which could not have reached the holder
either: the holder brings an audio system up, so libbela renames it a
moment into its life. It was raised three times while reviewing #163
and kept out of it deliberately — that change removes a guard, and
adding one is a separate decision.

What to do about it, in order:

1. Measure whether a `bela_daemon` started beside a held device does
anything at all. If it does not, the answer may be a line in the
script saying so rather than a `timeout`.
2. If it does, bound the holder the way everything else here is
bounded: `timeout -s INT -k 5 $((HOLD_SECONDS + N))`, with `N` the
margin the other runs use.