sync-to-zesty: recover from 'filename already exists' on POST

[ardeay]

Per ardeay (2026-09-09 Discord, Option A on the sync-to-zesty patch).

Problem

When `sync-to-zesty.js` runs a FULL_SYNC and encounters a file on disk that isn't in `zesty.config.json` yet, it POSTs `/web/` to create the view. If the fileName is already taken in Zesty (which happens whenever someone created the view manually in the editor at some point without its ZUID landing back in the config), Zesty returns:

```
400 Bad Request: filename already exists
```

The current script surfaces that as a thrown Error, which crashes the entire run — every subsequent file in `newFiles` never gets touched. Today's example: the run choked on `adobe-experience-manager-vs-content-one.html` and never even attempted to create the 4 pages sam and kaya are waiting on.

Fix

• `apiRequest()` attaches `.status` + `.bodyText` onto thrown Errors so callers can introspect
• `createNew()` wraps the POST in try/catch. On `400 filename already exists`, it calls a new helper `findExistingZuidByFileName()` that GETs `/web/`, scans the list for a matching fileName, extracts the ZUID, and returns it as if the resource had just been created. The workflow's existing "Commit new-resource ZUID mappings" step then writes that ZUID back into `zesty.config.json`, so subsequent runs treat it as a normal update-in-place.
• Any other 400 (or 401/403/etc.) still fails loud — this doesn't silently swallow real bugs

Also fixes a small `apiRequest` quirk: it used to serialize `body: undefined` as `"undefined"` via `JSON.stringify`. Now it only attaches `options.body` when there's actually a body — safer for GET/DELETE.

Test

`scripts/sync-to-zesty.test.js` — a small zero-config test that asserts the shape of the patch (recovery branch present, helper defined, body-guard in place). Run with `node scripts/sync-to-zesty.test.js`. Not wired into CI yet (would need a proper test runner) but it's easy to invoke locally.

Follow-up unblocked

Once this ships, a FULL_SYNC dispatch on stage will self-heal all ~15 currently-orphaned view records into `zesty.config.json` in a single run, eliminating the "manual ZUID hand-off after each new landing page" bottleneck that's been eating operator time all summer.

Test plan

• Stage CI passes on merge
• Dispatch FULL_SYNC on stage post-merge — no more crashes on filename conflicts; `zesty.config.json` gains all orphaned ZUID mappings

[github-actions]

💾 Stage sync preview

New files to create (0):
none

Will add/update — differ from dev (0):
none

Unchanged, skipped: 0

_{196 mapped resources · zesty-sync}