chore: point repo references at the renamed engine repos

[sairenchristianbuerano]

The COO and CTO renamed two repositories: trustabl/trustabl is now trustabl/agent-reliability-analyzer, and trustabl/trustabl-rules is now trustabl/agent-reliability-rules. The owner is unchanged and no other repo moved. GitHub redirects the old slugs indefinitely, so nothing here was broken, but the action is the surface most people read before they trust it - a Marketplace listing, a README badge, a security policy and an llms.txt that all name a repository that no longer exists by that name reads as staleness.

Changed, and only where the target is one of the two renamed repos:

• src/install.ts - RELEASE_REPO (the api.github.com/repos lookup for the latest release) and RELEASE_BASE (the release-download base URL). This is the only runtime behaviour in the diff.
• dist/index.js - rebuilt with npm ci && npm run build. dist is the artifact GitHub actually executes, so the source edit alone would have changed nothing at runtime. The bundle carries some unrelated churn from dependency modules being re-emitted by a clean ncc build; the only semantic change is the two constants above. Typecheck and the 67 tests pass.
• action.yml - the rules-ref and rules-repo descriptions, which render on the Marketplace listing.
• README.md - the downloads badge and its link, plus the two rules-repo rows.
• SECURITY.md - both links to the scanner repo, including the advisory route.
• llms.txt - the three raw.githubusercontent links to the engine's canonical llms.txt, README and COVERAGE.
• .github/workflows/download-history.yml and the stats JSON it writes - TARGET_REPO drives an api.github.com/repos releases call. The JSON's "repo" field is rewritten from TARGET_REPO on every run anyway; it is updated here so the committed file does not disagree with the workflow between runs. The recorded download counts are untouched.

Deliberately NOT changed:

• CHANGELOG.md. Three entries link or name trustabl/trustabl. They record what was true when they were written, and the links still resolve through the redirect. Rewriting them would make a true historical statement false.
• Everything named "trustabl" that is not a repository reference: the CLI binary and its release asset filenames (trustabl_.tar.gz, which have no redirect and would 404 on every published tag), the tool-cache entry, the SARIF tool name, the action's own repo trustabl/trustabl-action, the owner, and the product name throughout the prose. The product is not being renamed, only two repositories.

No bare find/replace was run on the token "trustabl".

[github-actions]

Trustabl scan

trustabl/trustabl-action · chore/rename-to-agent-reliability · 1 findings

Readiness goes from 100 → 100 (+0)

Readiness now   🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩   100 / 100

Projected if all findings resolved   🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩   100 / 100   +0

Findings by severity

Severity	Count
critical	0	▱▱▱▱▱▱▱▱
high	0	▱▱▱▱▱▱▱▱
medium	0	▱▱▱▱▱▱▱▱
low	0	▱▱▱▱▱▱▱▱
info	1	▰▰▰▰▰▰▰▰

Projected headroom — estimate, not a re-scan

Fix scope	Readiness	Δ
Fix critical	100 → 100	+0
+ high	100 → 100	+0
+ medium	100 → 100	+0
+ low	100 → 100	+0
+ info (all)	100 → 100	+0

Projected by re-applying trustabl's own scoring with the listed findings resolved (nothing new introduced). Treat as guidance, not a guarantee.

Metric	Value
Repository	trustabl/trustabl-action
Branch	chore/rename-to-agent-reliability
Readiness score	100
Risk score	0
Findings	1
Max severity	info
Native exit	0
Rules version	1ea4a53651db6590cde54a5d961d337365f37b3c

✅ Passed scanning