Extension build

Build and image standalone extensions

avocado ext build and avocado ext image previously hard-errored when an extension wasn't listed in a runtime's extensions:, which made it impossible to build a shared extension on its own — for example, to verify it compiles for a PR before wiring it into a runtime. Shared-extension configs have no runtimes: block at all, so the membership check could never pass for them.

The membership check is now a warning in both commands, consistent with avocado ext install (which already installs any extension into the runtime-scoped sysroot without requiring config membership). A non-member build/image still runs against the runtime's sysroot tree, the real guardrail (the rootfs sysroot must be populated by a prior install) stays in place, and the warning keeps an absent or mistyped extension name visible.

Bug fixes

• rootfs / initramfs / kernel path sources resolve against src_dir. Their source.path fragments now resolve against the configured src_dir — the same base that extension source: { type: path } sources use — instead of the config file's directory. avocado provision likewise reads the lock/state file and attaches the Docker volume keyed at the resolved src_dir rather than the current directory. This fixes "one runtime per directory" layouts where a board's avocado.yaml points src_dir at a parent (e.g. runtimes/<board>/avocado.yaml with src_dir: ../..), which previously resolved these paths against the wrong base.
• Security: bumped quinn-proto to 0.11.15 to resolve RUSTSEC-2026-0185 — remote memory exhaustion from unbounded out-of-order stream reassembly, pulled in transitively through reqwest's HTTP/3 support. Lockfile-only.