[vinniefalco]

The file tools now come from a dynamic library, the std Plugin, which Workshop loads when it starts. The code of that Plugin moved out of this repository to cppalliance/runvil-plugin-std, and crates/plugin-std is deleted. Twelve commits, 145 files. Most of the deleted lines are that crate.

For a library to offer real tools, the Harness's loader had to learn more of the C contract in cppalliance/runvil-plugin-api. It now speaks contract 0.4: a library Plugin can insert Packs, run a tool call in steps, and read a run's files.

The first commit is the one this pull request began with. It removes the non-Unix set_executable stub, so build-workshop passes clippy on Windows. The last three commits fix a flaky check in the Windows installer test and put a time limit on the package-install steps.

The loader (crates/harness-internal/plugin-loader):

• A library Plugin's Packs go into the PackRegistry. Each run gets its own instance of a Pack, and the Plugin stays loaded until the last instance is gone.
• A tool call runs as a series of steps. A run can be canceled between two steps, and the loader then tells the Plugin to free the call's state.
• A step reads files only through file_stat, file_list, and file_read, which the loader answers from the tool call's Access. So the run's policy applies to every read. A read the policy denies reaches the Plugin as a file error with the policy's own reason, and it does not fail the call.
• A panic in a policy or a backend under one of those functions becomes a file error, because a panic must not unwind through a C function.
• Each byte limit the loader enforces is checked at compile time against the contract's RV_MAX_ constant.
• PackOrigin::Linked is renamed PackOrigin::Plugin. That is the one change to crates/runvil/public-api.txt.

Workshop:

• Workshop loads every library in its Plugin directory when it starts. [agents] plugins in workshop.toml names another directory instead of the installation's own.
• Nothing links the std Plugin. crates/workshop/plugin-std is a small crate that builds the library with every Workshop build, from the commit the root Cargo.toml pins. cargo workshop copies it into plugins beside the development build.
• runvil-workshop --plugins prints each Plugin the installation loads and exits.
• A Workshop with no std library refuses an agent that requires std and says that runvil/std is not installed.

Installers:

• Windows: the NSIS setup installs plugins\plugin_std.dll with the Workshop component and removes it with it.
• macOS and Linux: Tauri copies the library into Workshop's bundle, at Runvil.app/Contents/Resources/plugins or at usr/lib/runvil/plugins in the AppImage. The updater replaces only that bundle, so the library must be inside it to change with Workshop. The installer build fails when the bundle lacks the library.
• cell.sh and cell.ps1 check that the library is installed and run --plugins, which must list std.

The workflows:

• The update-install check in cell.ps1 was flaky, and it is fixed here. The cell stopped the Gateway and then listed the model files. Windows keeps a stopped process in its list, with its files still open, while it tears the process down, and Wait-Process returns before that ends. So the listing was sometimes taken while the stopped Gateway still held its Speech to Text download open, and it showed a stale length. The cell now waits until a fresh process listing shows no Workshop and no Gateway, reads each file's length from the file itself, and compares only after two readings agree. This flaw was in the cell before this pull request and does not come from the std Plugin.
• The four steps that run apt-get install, in ci.yml and installers.yml, have a 20 minute limit. They normally take under a minute. When the Ubuntu mirrors do not answer, apt-get waits for a long time, and two of those jobs had no limit of their own.

Things a reviewer should know:

• The pins move together. A Plugin loads only in a Harness that speaks its exact contract version, so runvil-plugin-sys, runvil-plugin-sdk, and std-plugin in the root Cargo.toml name commits of one contract. They are at runvil-plugin-api 03a9fa3, tagged api-v0.4.0, and at runvil-plugin-std 782ad23.
• Two tool behaviors differ from the crate this removes. ListDir leaves out an entry whose name holds a control character and counts it in a note. Grep counts directories toward the work it does between two steps. Read, ListDir, and Grep are otherwise as they were, and Write, StrReplace, Delete, and Glob are still stubs.
• A config that sets [agents] plugins loads only that directory, so that directory must hold the std library too.
• Workshop installs no tracing subscriber, so the warnings about a library that does not load are written nowhere. --plugins is the way to see them.

Checks:

• Locally on Windows, at the commit before the last four, which change only cell.ps1 and the two workflow files: rustfmt, both clippy commands with warnings denied, both doc commands with -D warnings, cargo nextest (4106 and 497 tests), cargo test for build-xtask and build-workshop, docs-claims.mjs, cargo deny check, cargo xtask api --check, and cargo dylint.
• CI on this pull request is green at the head.
• The Installers workflow on this pull request passes at the head: all five builds and all ten install cells of its pull-request mode. On Windows, on macOS for both architectures, and on Linux for both architectures, the installed Workshop prints std 0.1.0 for --plugins.
• The full mode of the Installers workflow, dispatched on the fork at 3e5a260c0, passes with all seventeen install cells. The three commits after it change only cell.ps1 and the two workflow files.
• The flaky check: with the old script, test (windows, all) failed 2 times in 6 runs on one commit. With the script at the head it passed 11 times in a row, the run itself and ten re-runs of the job.
• Two earlier attempts of the runs at the head failed in apt-get, because the Ubuntu package mirrors did not resolve for a few hours on the day of this change. That outage is why the package-install limit is here.

Not checked:

• No run exercised the updater itself. Every cell installs fresh, so "the updater replaces the library with Workshop" rests on where the library sits, not on an update that was run.
• No test here runs a real Tauri build, so the configuration that copies the library into the bundle is proven only by the CI builds above.
• The fix for the flaky check rests on eleven passes and on the cause found in the cell's own output. The check has no test that forces the slow teardown.