PipeWire modifier parse fix, and a per-publication node execution boundary

[jcelerier]

Two changes needed by ossia/score#2270.

3rdparty: update libremidi. Picks up celtera/libremidi#255. extract_modifier_choice read a DMA-BUF modifier list at the wrong offset, dropping the first two entries and reading two past the end of the pod. A consumer then fixated on a modifier the producer never offered, and every Vulkan import of the shared buffer failed with VK_ERROR_OUT_OF_DEVICE_MEMORY. score's PipeWire DMA-BUF video input rendered black for this reason.

dataflow: expose a per-publication node execution boundary. A new graph_node::begin_execution(), called from both exec_node overloads right after init_node and before the token-slice loop. A node gets one call per graph execution, whatever number of slices that execution carries.

The gap it fills: prepare() is setup and run() is per-slice, so a node that accumulates across the slices of one execution had no way to know where an execution starts. It cannot be inferred from inside a slice, since a slice cannot tell whether it is the first, and transport time does not help when slices are zero-length, equal, or reversed. score's avendish binding uses it to reset the MIDI batch a processor emits across the slices of a tick.

Both exec_node overloads are covered; run_scaled is a declaration with no definition or caller, and nothing else drives a node's run().

Merge after the libremidi PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_019QWYTEhFJonuUNTEmBfv7Q