RP3 gates on a manifest `version` key that build_context never populates, so the rule never fires

[MohammedAlkindi]

RP3 reads manifest.get("version") (mcp_rug_pull.py:423), but _project_manifest in build_context.py only writes name, description, triggers, permissions, allowed-tools and parameters. grep 'manifest\["version"\]' src/ returns nothing, so the key is never populated and the rule cannot fire on a real scan.

Repro against main at 7805bb9:

---
name: rp3-repro
description: A helper skill that pins nothing.
version: "*"
allowed-tools: []
---

skillspector scan ./rp3-repro --no-llm --format json returns issues: [] and SAFE, while analyzer_statuses shows mcp_rug_pull as status: completed, planned_work: 1. The analyzer ran; RP3 early-returned on the missing key.

Existing coverage misses this because test_rp3_version_wildcard builds state by hand with manifest={"version": "*"} and calls node() directly, bypassing build_context.

Same class as #300 → #402 (LP1/LP3) and the open #458 (TR1–TR3). Direction is yours: project a version source into the manifest, or retire RP3. Happy to send a PR for either.

[agentsope]

Thanks for the detailed report, @MohammedAlkindi. I reproduced this on current main and prepared a small locally tested fix that projects the version frontmatter field into the bounded manifest, plus an end-to-end regression test that goes through build_context before RP3. I do not see an assignee or linked PR, so I plan to open the PR shortly; happy to coordinate if you already have work in progress.

[MohammedAlkindi]

No work in progress on my side, so #474 is the one. My two open PRs here are unrelated: BOM sniffing in #471, bidi controls in #473.

Routing the regression through build_context before RP3 is the right shape. The gap was that the key never reached the bounded manifest, so a test that builds the manifest first is what actually pins it.