FlatTermSelector: new term ID can be missing from save payload if post is saved before term-creation REST request resolves #78558

Description

In packages/editor/src/components/post-taxonomies/flat-term-selector.js, when a user adds a brand-new tag/term via the FormTokenField:

1. setValues( uniqueTerms ) runs synchronously and updates the component's local state (the chip is shown immediately).
2. findOrCreateTerm is called for each new token — this issues a POST /wp/v2/<taxonomy> to create the term and awaits the response.
3. Only after Promise.all(...) for those creates resolves does onUpdateTerms( ... ) run, which is the call that actually mutates the post entity's term IDs.

There is no lockPostSaving / unlockPostSaving guard around that promise chain. If the user clicks Publish/Update between step 1 and step 3, savePost() fires using the previous term IDs — the new term gets created in the database, but the post is saved without the association to it.

Re-saving the post a moment later persists the association correctly, so the bug looks like "I have to click save twice."

The relevant comment in the current source acknowledges the optimistic-update pattern:

// Optimistically update term values. The selector will always re-fetch terms later.

But "later" doesn't help if the user has already hit Save in the meantime.

Related (closed) issues:

These describe adjacent symptoms in the same component but don't address this specific race:
#15147 (taxonomy panel does not refresh on programmatic update)
#13282 (Tags constantly disappear in new posts)
#14428 (Tags disappear after updating posts)
#40850 (Cannot add tags to post — per_page: 20 search limit)
#11809 (lockPostSaving not working as expected — adjacent, different bug)

Step-by-step reproduction instructions

1. Fresh WordPress install. Use a non-hierarchical taxonomy (Tags is fine).
2. Open a new post in the block editor.
3. In the Tags panel, type a new tag name and press Enter.
4. Immediately (within ~500ms on a fast install, longer on slower/busy sites) click Publish/Update.
5. Reload the post.

Expected: the new tag is associated with the post.
Actual: the new tag exists in the taxonomy (it was successfully created), but the post is not associated with it. Saving the post a second time fixes the association.

The reproduction window scales with the latency of POST /wp/v2/<taxonomy>. On a vanilla install it's roughly half a second; on a site with significant per-request PHP overhead it widens to several seconds and is reliably reproducible by a normal-paced user.

Screenshots, screen recording, code snippet

No response

Environment info

WordPress: 7.0
Gutenberg plugin: tested in both core only and with Gutenberg 23.2.2
Browser: Arc 1.146.0 (80402), Chromium Engine Version 148.0.7778.97
OS: MacOS 26.5 (25F71)
Reproduced on a vanilla site with TT4 theme and all plugins deactivated. Originally noticed on a very busy site with a custom theme, several CPT's, and with slightly higher than ideal amount of plugins (35+) where the response required at least 3 seconds before saving/publishing would catch the new term ID in time.

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure