fix(secrev): hide dependency-cve canary manifests from dependency-review

The canary fixtures intentionally pin known-vulnerable deps (jinja2 2.11.2,
lodash 4.17.15) so the checker has something to detect. GitHub's dependency
graph parsed those fixture manifests as real project deps, failing the
dependency-review PR gate (fail-on-severity: high). Store the manifests with a
.fixture suffix so the dependency graph ignores them; the --canary materializer
strips the suffix in its temp work area before scanning, so detection is
unchanged (still 2/2). No advisory allowlist, no change to the shared org
reusable workflow — the real gate stays strict for actual deps.

security-review/checkers/dependency-cve.sh

@@ -354,6 +354,14 @@ if [ "$CANARY" -eq 1 ]; then
     nm="$(basename "$d")"
     cp -R "$d" "$FIXTURE_WORK/$nm"
     mv "$FIXTURE_WORK/$nm/dotgit" "$FIXTURE_WORK/$nm/.git"
+    # Manifests are stored as <name>.fixture so GitHub's dependency graph / the
+    # dependency-review CI action does NOT parse the deliberately-vulnerable canary
+    # pins as real project dependencies. Restore their real names in the materialized
+    # work area so the checker's per-ecosystem parsers dispatch correctly (same
+    # committable-without-side-effects rationale as the dotgit/ rename above).
+    while IFS= read -r ff; do
+      [ -n "$ff" ] && mv "$ff" "${ff%.fixture}"
+    done < <(find "$FIXTURE_WORK/$nm" -name '*.fixture' -not -path '*/.git/*' 2>/dev/null)
     REPO_NAMES+=( "$nm" ); REPO_DIR["$nm"]="$FIXTURE_WORK/$nm"
   done
 elif [ -n "$TARGETS_OVERRIDE" ]; then

security-review/checkers/fixtures/dependency-cve/README.md

@@ -32,3 +32,11 @@ regression in either parser is caught.
 When you add/remove a parser, a fixture, or an advisory entry, update the fixture(s),
 `osv-advisories.json`, and `EXPECTED_VULN_COUNT` in the same commit (the canary edit is
 itself caught on the next run — design §6.4).
+
+**Manifest naming:** the dependency manifests are stored with a `.fixture` suffix
+(`requirements.txt.fixture`, `package-lock.json.fixture`) so GitHub's dependency graph /
+the `dependency-review` CI action does NOT parse the deliberately-vulnerable canary pins as
+real project dependencies (which would fail the PR gate). The checker's `--canary`
+materialization strips the `.fixture` suffix in its temp work area before scanning, so the
+per-ecosystem parsers still dispatch on the real names. Keep this suffix on any new
+manifest fixture.