chore: regenerate admin-api types for nullable createSectionItem (HNT-2681)

[mmiermans]

Summary

Regenerates src/api/generatedTypes.ts to track the admin-api schema change in Pocket/content-monorepo#395 (HNT-2681), where Mutation.createSectionItem became nullable.

No application changes

This change just keeps the schema up-to-date; there's no impact to the admin tools from this.

The only consumer, CustomSectionDetails.tsx, calls runMutation(createSectionItem, …) and never reads data.createSectionItem, so the nullable type introduces no TS errors. Also note the null path is ML-only (gated on the ML service user); human curators using this UI never receive null.

[claude]

Claude finished @mmiermans's task in 49s —— View job

---

PR Review: regenerate admin-api types for nullable createSectionItem

• Gather context (read diff)
• Verify generated diff scope
• Verify consumers are unaffected by nullability
• Post review

---

Verdict: LGTM ✅ — clean, correctly-scoped generated-types update. Safe to merge.

Diff scope

The change is limited to exactly the two places the schema change touches, with no unrelated drift:

• Mutation.createSectionItem → createSectionItem?: Maybe<SectionItem> (+ updated schema description) — src/api/generatedTypes.ts:1259
• CreateSectionItemMutation result field → createSectionItem?: {...} | null — src/api/generatedTypes.ts:3253

This matches the upstream SectionItem! → SectionItem change in content-monorepo#395.

Consumer safety

The PR description states CustomSectionDetails.tsx is "the only consumer." There are actually two call sites — but the conclusion still holds, because neither reads data.createSectionItem, so the new nullability introduces no type errors:

1. CustomSectionDetails.tsx:334 — wraps the mutation in runMutation(...) and only uses the success/error callbacks; never touches the returned data.
2. ScheduleCorpusItemAction.tsx:114 — await createSectionItem({ variables }) with the result discarded; navigation keys off lastSectionId (the local loop variable), not the response.

So the "only consumer" note is slightly off, but immaterial to correctness.

Notes (non-blocking)

• A runtime null from this mutation is silently treated as success by both consumers (no data is read). That's the intended UX for the ML no-op path, and per the PR description that path is gated to the ML service user — human curators in this UI won't hit it — so no UI handling is needed here. Worth keeping in mind only if a future feature starts depending on the returned SectionItem (e.g. its externalId/rank), which would then need a null guard.
• Generated-only file; nothing to lint/test for behavior. No action required.
  · chore/regenerate-types-hnt-2681