platform: the dispatch envelope is a core table in every language, not a Java-only one

[swapnilpaliwal-sd]

Closes #471. Stacks on nothing, based directly on main (d54837c9, which is #453 merged).

The gap

call_edges says what the engine concluded. Nothing in the bundle said what the hierarchy
admitted, the set those edges were narrowed from, except in Java. The two core tables
that carry it were empty by construction in the other two front ends, measured on real runs:

	java	typescript	python
overrides	7,751 / 2,541 / 163	0	0
type_instantiated	3,906 / 306 / 263	0	207

schema_notes declared the emptiness in prose, so nothing lied. But bundle-test.sh asserts
the DDL of every non-ext table byte-identical across the three languages, and that assertion
actively hid this: the contract was identical in shape and not in content. Recovering the
fan meant dropping to ext_implementors (2 cols, type-level), ext_structural_implementor
(2 cols, type-level) or ext_mro_position (4 cols, positional), three different queries for
one question, none of which reaches a method.

None of it was missing analysis. It was computed and not projected.

What this adds

dispatch_candidates(base_method_id, candidate_method_id, basis)

	fed by	basis
java	virtual_override, as-is	nominal
typescript	implementors / structural_implementor × declared_method, joined on the member name	nominal, structural
python	type_ancestor reversed × mro_lookup	mro

plus TypeScript's missing RTA set, one projection over a relation that already held the answer:
type_instantiated(t, "new") :- new_expression_type(_, _, t).

overrides stays as the Java-shaped alias it is, documented as dispatch_candidates filtered
to basis = nominal. A new canonical query dispatch_envelope_of(:qualified_name) joins the
two tables and returns, per candidate, whether its owner is in the RTA set, the column that
lets a consumer narrow the envelope itself.

Reading mro_lookup, not type_defines_method

On the diamond fixture (A; B(A); C(A); D(B, C)) the Python rule yields:

mro  main.C.shared -> main.B.shared

A call resolving to C.shared runs B.shared on a D receiver, because D linearises
[D, B, C, A]. B is not a subtype of C, no "the subtype declares this name" rule
reaches that pair. That row is the whole reason the basis is called mro.

A constructor is not dispatched, and my first rule paired them

new Shape() runs Shape's constructor and never Circle's, however Circle extends Shape. The
first TypeScript rule paired them anyway, because a subclass constructor is a member of the
subclass with the same escaped name. Measured on 01-class-dispatch-and-super: 2 of 5 pairs
were Shape.<constructor> -> Circle.<constructor> and -> Square.<constructor>, edges no
run can take. Guarded. That case now reads:

nominal  shapes#Shape.area   -> shapes#Circle.area
nominal  shapes#Shape.area   -> shapes#Square.area
nominal  shapes#Shape.prefix -> shapes#Circle.prefix

three constructors declared in the file, none of them present. Java's virtual_override does
not have this defect (checked on two hierarchy cases). Python's __init__/__new__ are
excluded for the same reason: to Python's attribute machinery __init__ is an ordinary MRO
attribute, and mro_lookup cannot know the constructed class is written at the site.

Two departures from the issue

• mro_lookup is not exported. The issue proposed it; once dispatch_candidates exists
  nothing would query it, and it is (types × visible names × depth), an unmeasured bundle-size
  cost. ext_mro_position still carries the raw linearisation.
• basis is a string literal in a rule, which Python's literal gate refuses unless it is a
  declared language fact. It is not one, it is an output vocabulary term, written and never
  joined on, exactly the category of call_unresolvable and site_reason, so
  method_dispatch_candidate joins REASON_HEADS rather than the allowlist being widened.

Tests

Nothing downstream consumes this relation, so a rule that stopped emitting it would move no
other golden and no test would notice, which is how it stayed Java-only. Two layers read it now.

A per-case .envelope golden in all three suites (16 java, 18 typescript, 3 python).
Hash-free, so it is portable; the case's library IR is loaded so a library-declared base is
named (lib:dep.Strategy.run -> app.ExtImplA.run) rather than printing as an anonymous
lib:?; and the declaration line is appended where a qualified name is shared, because Java's
enum-constant fan prints three distinct methods under one name.

bundle-test.sh asserts the envelope and the RTA set are non-empty in every language,
inside the per-language loop rather than once outside it, an assertion that runs once passes
on Java and never looks. It discriminates: reverting the TypeScript and Python halves produces
12 failures, and Java passes either way, which is the asymmetry itself. TypeScript's fixture
also carries a duck type nothing constructs, so owner_instantiated is asserted to return both
values rather than being constant.

Verification

• java 39/39, typescript 53/53, python 15/15, all clean, no existing golden moved
• bundle: ok (3 languages, one schema across them, canonical queries run, schema doc current)
• Java's envelope equals virtual_override row-for-row on every case, it is a projection
• trial-merged into reshape (reshape: parser/ (subtree) + graph/ + bin/axiom-graph. One repository for the whole pipeline #469): every file lands in graph/ by rename detection, one
  trivial conflict (reshape renamed the bundle's CSV dir graph/ → csv/), and the bundle
  test passes there