Bowire: baixar versions anteriors

<One-sentence frame for what 2.5 is about. Replaces this placeholder
before the tag.>

## Highlights

<!-- Add a section per landed feature as the work merges. Pattern:
### <headline> (#issue)
<2-4 sentences>
-->

### The contract matrix — consumer × provider at a glance (#364)

`bowire contract verify` told you about one contract at a time. With a
handful of consumers against a handful of providers, "is anything broken
right now?" meant reading a pile of CI logs. Every verify run now stores
its verdict under `.bowire/contract-results/`, and that store backs a
matrix：rows are consumers, columns providers, each cell carries
pass/fail, how many interactions held, and when it last ran. Pairs nobody
verified show as blanks rather than silently missing.

The rollup is available from all four surfaces off one shared engine：the
**Contracts** rail in the workbench (grid plus drill-in to a failing
interaction's shape diff), `bowire contract matrix` (text grid, `--json`,
and `--fail-on-failures` as a CI gate), `GET /api/contracts/matrix`, and
the `bowire.contract.matrix` MCP tool, which hands an agent only what
broke per failing cell. Reading the matrix never contacts a provider — it
reports what verify already stored, so opening the rail cannot trigger an
outbound call.

Getting there meant lifting the verification engine out of the CLI
assembly, where it was `internal` and unreachable for the endpoint and
MCP, into a new **`Kuestenlogik.Bowire.Contracts`** package. It sits above
`Kuestenlogik.Bowire.Flows` (verification reuses the structural snapshot
comparer), ships the rail descriptor and its JS fragment, and is bundled
into the standalone tool — so `bowire contract` is unchanged and the rail
is simply there. Embedded hosts opt in by referencing the package, like
every other rail.

### Latency budgets that fail a pipeline (#360)

Benchmarks were informational：the workbench rail measured p50/p95/p99 and
drew the graphs, but the numbers lived in the browser, so no pipeline could
fail on a latency regression — the one thing k6 gets reached for. `bowire
bench run` puts the same measurement on the command line and adds budgets:

```bash
bowire bench run Weather/getCurrent -url rest@http://localhost:6000 \
-n 500 -c 8 --warmup 20 \
--threshold "p95 < 200" --threshold "error-rate < 0.01" \
--fail-on-threshold
```

A breached budget is marked in the summary with what it actually measured,
and `--fail-on-threshold` turns that into a non-zero exit. Budgets read
`metric operator value` over p50/p90/p95/p99/avg/min/max/error-rate/
throughput; k6's own `p(95)` spelling parses too, so a threshold can be
copied straight out of a k6 script.

`--k6-summary` writes the run in the shape the rail already exports (#234),
with each budget attached the way k6 reports its own — keyed by source text
inside the metric it constrains, with an `ok` flag — so a dashboard that
ingests k6 summaries finds Bowire's budgets where it looks for k6's.

The measurement itself is deliberately not a second implementation：the
runner drives `IBowireProtocol.InvokeAsync`, the same path `bowire call` and
`bowire test` take, percentiles use the rail's nearest-rank method, and
success/failure follows the same rule the workbench history uses. A p95 read
in the rail is the p95 CI compares against.

### One view over a portfolio of services (#587)

Per-service findings answer "is this service healthy?" — the rollup answers
it for a whole portfolio, and it needs nothing new to be produced. Every
signal it shows is an artefact some Bowire command already writes：lint
findings, contract-verification results, benchmark runs and k6 summaries,
scan SARIF, test JUnit.

```bash
bowire report rollup --from reports/ --fail-on high
```

```
SERVICE WORST LINT (H/M/L) CONTRACTS TESTS P95 LAST
billing-api HIGH — 0/1 — 312ms 2026-08-20
gateway HIGH — — — — —
orders-api MEDIUM 0/1/1 1/1 42/42 — 2026-08-19
```

An em dash means **there is no such report**, never zero：a service nobody
has linted mus

v2.5 is about what happens **after** you leave the workbench. The things Bowire already knew — your schemas, your recordings, your benchmarks, your contracts — now show up where the work actually gets judged：in CI, on a pull request, and in an editor panel next to the code.

215 commits since v2.4.0. Every workspace, collection, recording, mock and flow loads identically. Two changes are worth reading before you upgrade — see [Breaking changes](#breaking-changes).

## Highlights

### The workbench, in VS Code ([#101](https://github.com/Kuestenlogik/Bowire/issues/101))

`ext install kuestenlogik.bowire-vscode` opens Bowire in an editor panel beside your code.

It does **not** bundle a CLI — it drives one. The extension uses a `bowire` you configured, one your repository pins in a tool manifest, or one on your `PATH`, and offers to fetch a verified copy when it finds none. That is the whole point：the workbench in your editor, the `bowire` in your terminal and the one in CI are the same binary reading the same collections.

Uninstalling the extension removes a CLI it downloaded. One you installed yourself is never touched.

### Design-time lint — the review comments you keep writing ([#189](https://github.com/Kuestenlogik/Bowire/issues/189))

Most API design problems are caught in review *if the reviewer is sharp* — inconsistent naming, a field that returns a password, an unbounded list with no pagination, a missing version. That scales with reviewer attention, which does not scale.

`bowire lint <snapshot|url>` runs a typed rule engine over the schema and reports them without a reviewer having to be sharp that day:

```bash
bowire lint https://api.example.com --format markdown --fail-on high
```

Text for a terminal, markdown for a PR comment, JSON for whatever you build next. `--fail-on` gates the build — and `none` or an unrecognised level never fails, because a lint gate is advisory and a typo should not break a build that was passing.

### Latency budgets as CI gates ([#360](https://github.com/Kuestenlogik/Bowire/issues/360), [#232](https://github.com/Kuestenlogik/Bowire/issues/232))

k6-style thresholds：a budget is either met or the run exits non-zero.

```bash
bowire bench run Weather/getCurrent --url rest@http://localhost:6000 --threshold "p95 < 200" --threshold "error-rate < 0.01"
```

Budgets are plain numbers — milliseconds for the latency metrics, a
fraction for `error-rate`. Metric spellings are forgiving (`p(95)`,
`error_rate` and `error-rate` all land on the same metric), the budget is
not：a unit suffix is refused rather than guessed at, and every threshold
is parsed before the run starts so a typo in the fifth budget does not
surface after two minutes of load.

Benchmarks also gained a **scheduled** shape — a cron-driven run that survives a restart, with the schedule readable and pausable from the workbench. Deliberately no "create" button in the browser：a schedule carries a target URL the server will call unattended, so authoring one stays on the CLI where the operator is explicit about it.

### Contract matrix in the workbench ([#364](https://github.com/Kuestenlogik/Bowire/issues/364))

Consumer × provider, pass/fail, in one grid. Each cell carries how many interactions backed the verdict — 11 of 12 and 0 of 12 are very different mornings — and a pair that was never run reads as a dash rather than a blank, which would look like "checked, nothing wrong".

### One rollup over the artefacts you already write ([#587](https://github.com/Kuestenlogik/Bowire/issues/587))

Lint findings, contract results, benchmark envelopes, k6 summaries, SARIF, JUnit — Bowire already wrote all of it as structured files. `bowire report rollup` reads them into one portfolio view, available identically from the CLI, `GET /api/report/rollup`, and the `bowire.report.rollup` MCP tool.

Counts stay nullable on purpose："no lint report was read" and "lint found nothing" are different statements, and flattening both to zero would let a missing