fix: fail closed on invalid project resources

[andrei-hasna]

Summary

• prefer the canonical HASNA_KNOWLEDGE_API_URL and API-key environment names
• validate hosted project-resource page and exact-read envelopes instead of casting arbitrary JSON
• preserve structured project-link error codes in CLI JSON output

Verification

• bun test tests/hosted-config.test.ts tests/project-links.test.ts
• bun test
• bun run build
• bun run test:package
• bun run release:pack:check
• bun run contracts:conformance
• bun run verify:generated
• staged and commit-range gitleaks scans: no leaks

Tracks KNO-00027 (2bc93b77-d5c1-4b08-b02b-ed607df467a2).

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[andrei-hasna]

[REVIEW] GO for exact head c4718c2889fbe291978ad138847ed30fe3ec1f29 against base a1af5416e83212ec5941df759564e847c8261a6c.

No reachable in-scope P0/P1 defect found. Canonical HASNA URL precedence is correct; malformed 2xx page/exact envelopes fail closed with the typed project-links error; CLI JSON emits ok:false and exits 1. Focused local gate: 15 pass, 0 fail. Required seven-job CI matrix is terminal SUCCESS. Redacted exact-range scan printed no leaks found; firing control printed leaks found: 1. Main still equals the reviewed base. Merge/publish/install/live proof remain executor gates.

[andrei-hasna]

[REVIEW] NO_GO — #92 @ c4718c2 — lens: correctness+isolation+wiring, reviewer codewith-sol-reviewer (1 of 1)

P0: None found.

P1 — src/project-links.ts: the new success-envelope validators are not bound to the request. listProjectResources(projectId) accepts a structurally valid page whose project_id/source_project_id and every resource belong to another project. readProjectResource(projectId, kind, resourceId) likewise accepts a resource with a different project, kind, or id. The CLI then labels that payload as the caller's exact requested result. A wrong-project 2xx from the hosted route therefore crosses the client isolation/exact-read boundary instead of failing with KNOWLEDGE_PROJECT_LINKS_INVALID_RESPONSE. The added tests cover malformed shape only; they have no mismatched-project/kind/id negative control.

P1 — src/cli.ts / src/auth.ts: canonical credential precedence is only partially wired. This diff makes auth resolution prefer HASNA_KNOWLEDGE_API_KEY over compatibility alias KNOWLEDGE_API_KEY, but knowledge auth login still selects KNOWLEDGE_API_KEY first. When both are set, status/runtime auth uses the canonical key while login persists the alias key; with the new canonical URL precedence it can persist an alias credential against the canonical endpoint. This directly defeats the claimed canonical routing and can authenticate or store credentials for the wrong account/tenant.

P2: None recorded. P3: None recorded.

Could not verify: the exact head was not available in the local checkout, so I did not execute its tests or a live hosted request. Review evidence is the supplied exact-head diff plus read-only inspection of unchanged call sites; no repository was modified and no merge was attempted.