Inline TableInterfaceField and TableMethodField children (currently N+1)

A child @table field backed by a polymorphic interface target (ChildField.TableInterfaceField) or by a @tableMethod (ChildField.TableMethodField) is reachable by FK correlation from a query-scope parent, so it should inline into the parent query as a correlated subquery / DSL.multiset(…​), exactly like the ordinary ChildField.TableField (InlineTableFieldEmitter). It does not. Both leaves get a generated synchronous fetcher method (TypeFetcherGenerator.buildTableInterfaceFieldFetcher, buildChildTableMethodFetcher) that runs its own per-parent dsl.select(…​).from(…​).where(parent-correlation).fetch() against env.getSource(). There is no SplitRowsMethodEmitter and no DataLoader registration for these, so the fetcher fires once per parent row: an N+1 query pattern. N+1 is never correct.

The correct target is to inline these the way TableField / LookupTableField are inlined (a correlated multiset folded into the parent SELECT, with the polymorphic discriminator / participant joins expressed inline for the interface case, and the developer-supplied jOOQ table spliced into the multiset for the @tableMethod case). Inlining is possible for both; support simply has not been built out (@tableMethod in particular has had little work). At minimum, if a separate execution turns out to be genuinely required for some shape, it must be a keyed batch (DataLoader, as SplitTableField / RecordTableField do via SplitRowsMethodEmitter), never a per-parent sync query.

Surfaced during R281 dimensional-model design (the producer x mapping cut). It is the textbook current implementation != what’s correct divergence the R281 corpus exists to enforce: these leaves are classified producer = ∅ (inline), and this defect is the gap between that correct verdict and the current generator. R281 asserts the correct classification; this item fixes the generator to match. See graphitron-rewrite/roadmap/classification-test-dsl.md, the current-vs-correct note under producer.