[jcelerier]

Four independent fixes around camera inputs, plus one CI fix. Each is described
by what was measured, and where an earlier claim in this PR turned out to be
wrong it is corrected below rather than quietly dropped.

1. A removed camera node left its capture running

video_texture_input_protocol::stop_execution() is the only thing that closed a
camera, and it is guarded on camera_node — which
~video_texture_input_parameter() sets to null as its first statement, so once
the node is gone the function is a no-op. Nothing else closed the device:
~video_texture_input_protocol() is empty, and ~CameraInput() only runs when
the last shared_ptr to the camera dies, which the render node holds and the
nursery releases from a 100 ms QTimer.

The destructor now arms the stop before unregistering the node, and
stop_execution() stops the camera directly when there is no render node, since
nothing can be rendering from it then.

Verified on Windows by logging every CameraInput::close_file() with its format
context:

start OK   this=CF65E870 fmt=6648B640 640x480
close_file this=CF65E870 fmt=6648B640 running=1   <- real context, still running
close_file this=CF65E870 fmt=       running=0     <- idempotent second call
deviceRemoved iface=6BA6B170 live=CF65A160        <- only now does the device go

That close is not ~CameraInput: the same object receives further close_file
calls afterwards, so it was still alive.

Correction to this PR's earlier description. It claimed the sequence's third
open never completes. It is the second, and the first version of this PR was
measuring the wrong thing — the scenario's opened N marker only means
NodeStore.create returned an id, which it does whether or not the capture
opened. Instrumenting start_execution gives ok=1, ok=0, ok=1.

The frame-safe must_stop path is also defensive rather than load-bearing:
avformat_close_input does have to come after the rendered frames are released,
and REMOVE_NODE walks exactly there, but in this removal sequence
stop_execution finds camera_node null every time — 4 calls, 0 deferrals — so
the direct stop is what runs.

And closing promptly does not make the device immediately re-openable. In the
same run the next open still failed with Could not run graph (… device already in use …) two seconds after score had closed its own capture. That is dshow
releasing on its own schedule, not a leak on this side.

2. The camera's fallback open was skipped exactly when it was needed

CameraInput::start() retries with default settings when the requested mode
fails, but the retry was guarded on !m_interrupt.aborted() via expired(),
which is also true once open_timeout has merely lapsed — precisely the case
the fallback exists for. So a slow open became a hard failure with no retry, and
the fallback shared the first attempt's leftover budget.

Observed directly: open failed aborted=0 expired=1. The retry now gets its own
LibavTimeout, and in the instrumented run round 3 only succeeds because of it.

3. Syphon picked its decoder from whether a server was found

Unrelated to the above; verified on Apple M2 Pro under Metal.

4. A previously pinned addon stayed on a detached HEAD

clone_addon's unpinned-update branch ran git pull --ff-only against a
detached checkout left by an earlier pin, which fails, so the addon silently
stayed at the old commit. Reproduced in isolation and fixed by moving the
checkout back onto the remote default branch first.

Merge order: this needs
ossia/score-addon-videoio#12 merged first. master
already tracks videoio master, which still lacks <stdlib.h> for ::free, and
existing checkouts are shielded only by the bug this commit removes.

5. A camera that could not start said nothing

ExternalInput::start() returns a bool and start_execution() discarded it, so
a failed open was silent: node present, no frames, nothing in the log. It now
warns, so the Messages panel shows it.

To be explicit about what this is not: it does not make a failed open
observable outside the process. In --ui mode score installs no Qt message
handler at all — SafeQApplication installs DebugOutput only under
SCORE_DEBUG, and the Messages panel that would forward to stderr is not loaded
without the GUI. Measured with the camera held by another process for a whole
run: three opens refused, this warning emitted three times, zero lines on
stderr.

What this PR no longer claims to fix

An earlier revision carried a commit that unregistered a removed device from the
execution state, presented as the fix for a Pure virtual function called abort
seen while cycling cameras. It has been dropped, because it does not fix that
crash and cannot. Instrumenting the state's identity at every lookup showed the
abort happens on an abandoned execution_state:

findNode st=D8494F80 n=4: … CF65A010   <- current state, live camera
findNode st=6B9CBDC0 n=4: … CF659D70   <- abandoned state, camera removed earlier
libc++abi: Pure virtual function called!

ContextData is replaced wholesale, and its use_count at teardown is
sometimes 2 — the aliasing shared_ptrs handed out by
acquireExecutionQueue()/acquireGCQueue()/weakSelf() keep the whole
ContextData, and therefore its execution_state, alive with every device
pointer still registered in it. get_name() is non-virtual over the pure
virtual get_root_node(), so walking a destroyed device aborts; whether it
surfaces as the pure-virtual abort or a plain SIGSEGV depends only on what has
overwritten the vtable by then. Both were observed from this one cause.

The dropped commit operated on the current state, which the stale devices are
not in. That crash is a separate bug and is not addressed here.

Testing

Regression cover lives in sat-mtl/scenic-native
(sat-mtl/scenic-native#4): camcycle, camleak,
camregap, camstop. They judge an open on the /dev/video* descriptors
score's own process holds, having been validated in both directions against
instrumented ground truth — camera free → 3/3 PASS, camera held by another
process → 0/3 FAIL, matching start_execution's per-round ok= exactly.

All four pass on this branch on Linux. camleak and camstop were also checked
with and without fix 1 on Linux and are unaffected there, as expected: v4l2 is
not exclusive and drops the handle promptly, which is why this defect shows on
Windows.

🤖 Generated with Claude Code

https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq

[coveralls]

Coverage is 48.078% — fix/camera-release-and-syphon-metal-decoder into master. No base build found for master.

[jcelerier]

Merged into #2326 (gfx/shading-tiers) at 7f22521. libossia resolved to master 3e7ee8462e (same tree as c5d5ed307b). Closing in favour of #2326.