fix(types): include triggerOnView on DOMChangeCreate

[joalves]

Summary

Reverts my wrong call from PR #24. I had removed `triggerOnView` from the 'create' branch of `useDOMChangesEditor` (and from the `DOMChangeCreate` type) on the rationale that "the change itself inserts the element, so there's nothing to gate on viewport intersection". That conflated two concepts:

• Applying the change — yes, 'create' inserts the element itself; nothing to gate.
• Exposure tracking — the experiment-exposure firing semantic. Independent of element existence; works the same on create as on every other change type.

The SDK plugin's `ExposureTracker` (core/ExposureTracker.ts:67-87) handles `move` and `delete` specially (placeholder elements for cross-variant tracking), then has an `else` branch that catches every other change type — including `create` — and tracks `change.selector` for viewport intersection. So when the user ticks "trigger on view" on a 'create' change in the editor, the SDK is set up to honour it; the field was just silently being dropped at save time.

Changes

• `DOMChangeCreate` type now carries `triggerOnView?: boolean` like every other change interface in the file.
• `useDOMChangesEditor` 'create' case serialises the field alongside the existing per-type lines.

Test plan

• `bun run typecheck`
• `bun run test:unit` — 3034/3034 pass
• CI green

Summary by CodeRabbit

Release Notes

• New Features
  • DOM creation changes now support viewport-gated exposure tracking. Exposure events for newly inserted elements can be configured to fire only upon visibility, bringing consistency with other change types.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e18cba20-293c-4321-8347-f127b549b9a2

📥 Commits

Reviewing files that changed from the base of the PR and between 9b53e0e and 4b7c9f3.

📒 Files selected for processing (2)

• src/hooks/useDOMChangesEditor.ts
• src/types/dom-changes.ts

---

Walkthrough

The DOMChangeCreate interface in src/types/dom-changes.ts is extended with an optional triggerOnView?: boolean flag to support viewport-gated exposure firing. Correspondingly, src/hooks/useDOMChangesEditor.ts updates its handleSaveChange function to persist the triggerOnView property when saving "create" type DOM changes, aligning them with other change types that utilise exposure-tracking semantics based on element visibility.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 A viewport's dance, a flag so fine,
Create changes now in view align,
Exposure waits where pixels gleam,
Independent, yet serene—
Our burrow's logic, bright and keen! 🥕✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix(types): include triggerOnView on DOMChangeCreate' clearly and specifically describes the main change: adding the triggerOnView field to the DOMChangeCreate type interface.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/dom-create-triggeronview

---

_{Review rate limit: 4/5 reviews remaining, refill in 12 minutes.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}