docs(adr): amend ADR-0028 — a concrete projection owns its source

[dmealing]

Records the doctrine behind ERR_PROJECTION_INHERITED_SOURCE (shipped in bdeb4765): a concrete object.projection declares its own source.*; an abstract projection base carries shape only.

Why this needed writing down

The rule looks arbitrary until you see which of two inheritance regimes a projection belongs to — and the prior art is decisive on the split:

regime	binding inherited?	writability inherited?	examples
shared storage	yes	yes, with the binding	Hibernate @Immutable (inherited by entity subclasses), EF Core keyless ToView, SQLAlchemy single-table
shape reuse	no	n/a — the concrete class binds its own	JPA @MappedSuperclass ("has no separate table defined for it"), Django abstract bases

A projection is the second kind. Django documents inheriting db_table from an abstract base as a trap in almost these words: "all the child classes … would use the same database table, which is almost certainly not what you want." No surveyed system permits the unguarded middle MetaObjects had — binding inherited, kind not.

Also records why the fix guards the shape rather than flipping a predicate. "Which source am I bound to" is resolving because entities legitimately inherit their table (TPH / BaseEntity); "what KIND of source am I" is own-only because projection-ness belongs to the declaring object. Both are correct for what they were designed for — only their intersection was incoherent, and it produced no working artifact in any of the five ports (TS mounted writable CRUD over a read-only view; Java/Kotlin skipped on subtype; Python on resolved kind; C# emitted nothing).

Also here

The metaobjects-authoring skill gains the rule plus its sanctioned pattern — abstract sourceless base, each concrete projection declaring its own view — so an agent authoring a versioned projection declares v_customers_v2 instead of silently sharing V1's view. Bundled into the sdk copy and the four agent-context-conformance goldens.

Not included: #270

#270 was scoped as "retire the redundant Kotlin/Python payload origin-typing." Its premise is falsified the same way #271's was. The redundancy claim holds for origin.passthrough (type-preserving since #185) but not for origin.aggregate (count→Long, avg→Double) or origin.collection (→List<TargetPayload>), where the origin genuinely determines the type and the declared field type cannot express it. The corpus exercises exactly those — origin-collection-simple and flattened-kitchen-sink both carry origins on object.value. Deleting the handling would not be byte-identical; it would either break type derivation or make Kotlin match TS's origin-blindness, which may itself be the defect rather than the baseline. Needs its own recon before anything is deleted.

Gates

Docs + skill only — no product code. TS typecheck clean; sdk suite green (150); agent-context goldens regenerated and matching.