Port or retire the Teradata graph-lineage and catalogue-interface templates #78

PR 77 moved every binding onto the build context. Two sets of Teradata templates were not moved: they read the old flat template context and no phase renders them.

• Graph lineage: implementation/teradata/modules/observability/05-graph-tables.sql.j2 to 10-access.dcl.sql.j2 (about 590 lines), the optional observability:graph-lineage facet.
• Catalogue interface: implementation/teradata/patterns/catalogue-interface/ (about 1,380 lines), the binding of design/patterns/catalogue-interface.md, with the examples in examples/alation-interface/.

Effect. Two test_binding_package tests fail on these templates alone (one reports a template rendered by nothing, one a colon-named parameter in 02-lifecycle-dml.sql.j2), so CI cannot go green. Both capabilities are reported as gaps.

What a port needs. Placement is the open design question. The old templates compose database names from the product name and read governance_db, stage and graph_key; no standard places a governance, stage or graph container. The profile standard needs to say where those come from, the resolver needs to place them, and the templates then read the placed names. The catalogue's relationship and semantic-model queries also need updating for the 2.0.0 metadata contract (PR 76).

Proposal. Do not delete the templates and do not exempt them from the tests. Settle the placement design first, then port them in a follow-up PR after PR 77 merges, verified on a Teradata system.

Decisions needed. Port or retire; both capabilities or graph lineage first; whether they should exist on other platforms.

Related: #77, #76.