fix(ci,docs): repair install path and attestation references

[aram-devdocs]

Summary

• Wires plumb-cli-installer.sh, plumb-cli-installer.ps1, and schemas/plumb.toml.json into the deployed mdBook so the documented one-liners and the starter plumb.toml $schema URL stop 404'ing.
• Switches pages.yml from push: main to release: published so the docs site is versioned per release. Stamps the latest release tag into a theme/head.hbs override and into book/version.txt for tooling.
• Fixes install-smoke.yml asset filenames (plumb-cli-installer.{sh,ps1}) and adds a workflow_dispatch.inputs.tag input for ad-hoc smoke runs.
• Corrects four gh attestation verify examples plus the "What gets attested" table in docs/src/install.md to use real plumb-cli-... asset names; bumps pin example from 0.0.9 to 0.0.11.
• Investigates install.ps1 SHA-256 verification — cargo-dist 0.28's installer.ps1.j2 has no verify_checksum helper (string-grep confirmed). Documented as a Windows note; deferred to a follow-up since wrapping the cargo-dist installer is outside this PR's scope.

Closes audit findings B1 (install path 404), B6 (schema URL 404), H1 (attestation example asset name), H3 (smoke workflow asset name), H8 (pin-version stale), and the "version the docs site via release-please" ask.

H2 (install.ps1 sha256 verification) deferred — see the Windows note in install.md.

Test plan

• just validate passes locally.
• just install-smoke-validate passes (validator updated alongside the asset rename).
• mdbook build succeeds; the __PLUMB_VERSION__ sentinel survives Handlebars rendering and reaches the deployed HTML.
• After merge: curl -fI https://plumb.aramhammoudeh.com/install.sh returns 200.
• After merge: curl -fI https://plumb.aramhammoudeh.com/install.ps1 returns 200.
• After merge: curl -fI https://plumb.aramhammoudeh.com/schemas/plumb.toml.json returns 200.
• After merge: curl -fI https://plumb.aramhammoudeh.com/version.txt returns 200 with the published tag as body.
• Manual gh workflow run install-smoke.yml -f tag=v0.0.11 passes on every leg.

🤖 Generated with Claude Code

[github-actions]

I have everything I need. Here is the full review.

---

PR #278 — feat(core): apply [rules.<id>].severity overrides at engine layer

Files: engine.rs (+18/-3), tests/severity_override_engine.rs (+138), docs/src/cli.md (+8/-2), Cargo.lock (version sync)
Buckets: plumb-core, docs

---

1. Determinism — PASS

The remap is inside the flat_map closure, operating on a local: Vec<Violation> that is owned by that closure. Each rule's closure reads config.rules (an IndexMap) via a deterministic key lookup, applies the override uniformly to every violation, then returns the local vec. Rayon combines results via collect(), which feeds the existing sort_by(sort_key) + dedup. The sort key is unchanged: (rule_id, viewport, selector, dom_order). No wall-clock, no RNG, no env access. Determinism guarantee preserved.

2. Workspace layering — PASS

All changes are within plumb-core. The integration test imports only plumb_core symbols — correct for crates/plumb-core/tests/. No new internal deps. plumb-format was checked: it reads v.severity as-is and has no config-based remap path, so the engine is now the canonical and sole override point. No layer violations.

3. Error handling — PASS

No unwrap/expect/panic! in library code. The override is applied via if let Some(override_severity) = ... pattern. Severity derives Copy, so violation.severity = override_severity is a safe field assignment with no allocation or failure mode. Clean.

4. Test coverage — WARN (non-blocking)

Four tests cover the primary contract surface:

Test	Scenario
severity_override_promotes_warning_to_error	Override upgrades severity
severity_override_demotes_warning_to_info	Override demotes severity
no_override_preserves_default_severity	Baseline: no remap without override
override_on_unknown_rule_id_is_ignored_cleanly	Unknown ID: no panic, no bleed

Two untested edge cases:

• enabled = false + severity = Some(...): the .filter() gates out disabled rules before the flat_map override runs, so no violation is emitted. Behavior is correct but unexercised. (engine.rs:195-197)
• Severity-overridden violation matched by an [[ignore]] entry: override is applied in run_rules; apply_ignores runs after in run_report. Correct ordering, but no test asserts this.

Neither is a blocker — both rely on trivially composed existing paths — but a follow-up ticket would be warranted.

Coverage gap: exit_code_for is not tested with a severity-overridden violation end-to-end (the PR defers the E2E smoke to post-merge). The function itself already handles Severity::Info => {} at lint.rs:357, and the docs update is accurate. Acceptable gap for a pre-merge review.

5. Documentation — PASS (micro-warning)

docs/src/cli.md correctly updates the exit code table (0 now explicitly covers info-only runs) and adds a clear paragraph on the info bucket's role. No items from the anti-AI-writing list in documentation.md appear. The word "surfaced" (cli.md:47) has a slight AI-writing feel but is not on the explicit blocklist and reads naturally in context.

---

Punch list

Severity	Location	Finding
Warn	engine.rs:195,205	Double IndexMap lookup per rule: .filter() calls config.rules.get(rule.id()) and flat_map calls it again. O(1), so no perf impact at rule counts, but worth noting as future cleanup.
Warn	tests/severity_override_engine.rs	No test for enabled = false + severity = Some(...) combo.
Warn	tests/severity_override_engine.rs	No test for override + [[ignore]] interaction (override runs first, ignore second).
Info	docs/src/cli.md:47	"surfaced" — marginal AI-tell, not on hard blocklist.
Info	Cargo.lock	Lock file brought from 0.0.6 to 0.0.11 (matches workspace Cargo.toml). Expected, not a concern.

---

Verdict: APPROVE