test(e2e): nested object-type name-collision case (ENT-82) — bug-reproducing (#132)

* test(e2e): add nested object-type name-collision case (ENT-82)

Reproduces the nested object-type name-collision bug end-to-end: two
indices (orders_primary, orders_secondary) define object fields `subject`
and `audit` with DIFFERENT shapes. On the current connector the bare-name
NDC object types collide in a single global map (last-writer-wins,
nondeterministic Go map order), silently dropping the fields that exist
only in the fuller definition (subject.alternateAccountIdentifier,
subject.businessSystemCode, and the audit index:false leaves); queries
selecting those fields then fail GraphQL validation.

This case is intentionally FLAKY/RED on main -- it encodes the bug. It
becomes deterministically green once the always-fully-qualified fix (#123)
lands, at which point the pending goldens are regenerated (UPDATE_GOLDEN=1)
to capture the fixed schema + query results.

Verified locally: red (minimal shape wins) on the pre-fix connector; green
end-to-end on a connector built from #123 -- both indices return every
selected nested field and the DDN CLI keeps the two fully-qualified object
types (orders_primary.subject vs orders_secondary.subject) distinct.

Goldens are committed as {"__pending__": true} sentinels (comparison
skipped) until #123 regenerates them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(e2e): capture nested_collision baseline goldens (pre-fix)

Fill the pending schema + query goldens with the current (pre-fix) connector
output. These are the bare-name, buggy baseline: both indices share a single
`subject`/`audit` object type, so the snapshot reflects whichever shape won
the nondeterministic collision this run (the fuller shape here). They are
flaky on main by design; #123 makes the schema deterministic (fully-qualified)
and these goldens are regenerated to match then.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: m-Bilal

e2e/cases/nested_collision/case.yaml

@@ -0,0 +1,11 @@
+description: >
+  Nested object-type name collision across two indices (ENT-82 / Zendesk #14975).
+  Both orders_primary and orders_secondary define object fields `subject` and
+  `audit`, but with DIFFERENT shapes. Before the fix, the connector keyed NDC
+  object types by their bare name, so the two `subject` (and two `audit`)
+  definitions collided in a single global map — last-write-wins, nondeterministic
+  Go map order — silently dropping the fields that existed only in the fuller
+  definition (e.g. subject.alternateAccountIdentifier, subject.businessSystemCode,
+  and the audit index:false leaves). The always-fully-qualified fix keeps them
+  distinct (orders_primary.subject vs orders_secondary.subject), so no fields are
+  dropped and the queries below keep returning every selected field.

e2e/cases/nested_collision/data/orders_primary.ndjson

@@ -0,0 +1,6 @@
+{"index": {"_index": "orders_primary", "_id": "OP-1"}}
+{"orderId": "OP-1", "amount": 150.0, "subject": {"type": "wire", "alternateAccountIdentifier": "ALT-1", "businessSystemCode": "BSC-1"}, "audit": {"dtLastUpdated": "2024-01-01", "hash": "h1", "mode": "auto"}}
+{"index": {"_index": "orders_primary", "_id": "OP-2"}}
+{"orderId": "OP-2", "amount": 50.0, "subject": {"type": "ach", "alternateAccountIdentifier": "ALT-2", "businessSystemCode": "BSC-2"}, "audit": {"dtLastUpdated": "2024-02-01", "hash": "h2", "mode": "manual"}}
+{"index": {"_index": "orders_primary", "_id": "OP-3"}}
+{"orderId": "OP-3", "amount": 250.0, "subject": {"type": "wire", "alternateAccountIdentifier": "ALT-3", "businessSystemCode": "BSC-3"}, "audit": {"dtLastUpdated": "2024-03-01", "hash": "h3", "mode": "auto"}}

e2e/cases/nested_collision/data/orders_secondary.ndjson

@@ -0,0 +1,4 @@
+{"index": {"_index": "orders_secondary", "_id": "OS-1"}}
+{"orderId": "OS-1", "amount": 75.0, "subject": {"type": "card"}, "audit": {"dtLastUpdated": "2024-01-05"}}
+{"index": {"_index": "orders_secondary", "_id": "OS-2"}}
+{"orderId": "OS-2", "amount": 125.0, "subject": {"type": "cash"}, "audit": {"dtLastUpdated": "2024-02-05"}}