Retire shallow wrappers in lib/governance/ (project-framing, cross-project-fk)

[ProfessorPolymorphic]

What to build

Two modules in lib/governance/ fail the deletion test:

lib/governance/project-framing.ts mirrors slug → framing copy that already lives canonically in lib/portfolio.ts. The file's own comment acknowledges the duplication: "when facts diverge, portfolio.ts wins." This is a second source of truth that's stale by design.

lib/governance/cross-project-fk.ts ships with empty data, waiting for the upstream catalog convention to encode cross-project foreign keys. It's a placeholder seam — one adapter, no real adapters, no current consumers depending on its shape.

This issue is HITL because it asks a real call: is cross-project-fk.ts imminent (upstream convention landing soon), or vestigial? The answer determines whether to delete it now or document the intent and revisit.

For project-framing.ts: retire it, have governance pages read framing directly from the canonical Project entry in portfolio.ts. Single source of truth.

For cross-project-fk.ts: needs a decision before action.

lib/governance/glossary.ts and lib/governance/vocabulary-usage.ts are smaller and may have multiple consumers — leave alone unless inspection during this work shows they're also single-consumer pass-throughs.

Acceptance criteria

• Decision recorded (in this issue or as an inline ADR addendum) on cross-project-fk.ts: keep dormant, delete now, or wire up
• lib/governance/project-framing.ts deleted; consumers read framing from lib/portfolio.ts
• No drift possible between portfolio framing and governance framing — they're the same field
• npm run build and npm run build:governance pass
• Governance Drift CI workflow remains green

Blocked by

None - can start immediately