chore(tiktok): log fail_reason when a post stays in progress

[giladresisi]

What kind of change does this PR introduce?

Logging only, for troubleshooting. No behaviour change.

Why was this change needed?

Multiple users are hitting the same TikTok failure: the post is accepted by TikTok and comes back with a publish id, but every subsequent status check reports the post as still in progress for the entire 30 minute polling window. It never reaches PUBLISH_COMPLETE and it is never returned as FAILED, so we exhaust the checks and mark the post as unconfirmed, which is all the user sees.

These posts do not appear to publish at all. One affected user posts image carousels to their TikTok inbox and reports the content never arrives there; another hits the same thing with direct posts. So the format is common to both, the posting method is not, and in every case TikTok gives us no reason we could show the user.

TikTok's status response includes a fail_reason field alongside status. Today we only benefit from it on FAILED, where handleErrors already matches the spam_risk* values and surfaces them; on every other status we read status and drop the rest. If TikTok ever populates fail_reason while still reporting the post as in progress, that is exactly the explanation we have been missing, and it would also give us a stop condition for the polling instead of waiting out the full window and giving up.

This logs the field only on the path that returns "still pending" - after the two success branches and after FAILED - so nothing is logged when the API behaves as documented. It is a no-op in the healthy case.

Other information:

Deliberately observe-only. The value is logged and nothing acts on it, because failing a post on an undocumented signal could kill publishes that would otherwise have completed. Once we have real values we can decide whether to end the polling early on it.

Trade-offs worth knowing:

• If it does fire, a single stuck post can log up to 90 lines, one per poll (maxPendingChecks = 90 at 20 second intervals). Noisy per incident, but only in the case we want to see, and these are rare.
• We will not see fail_reason if it only ever arrives on a status we treat as successful. That is intentional: the post published either way, so it would be logging for nothing.

Reference: https://developers.tiktok.com/doc/content-posting-api-reference-get-video-status

Checklist:

Put a "X" in the boxes below to indicate you have followed the checklist;

• I have read the CONTRIBUTING guide.
• I have signed the Contributor License Agreement (CLA) (ICLA for individuals, CCLA for entities).
• I confirm I have not used AI to submit this PR or generate code for it.
• I checked that there were no similar issues or PRs already open for this.
• This PR fixes just ONE issue

[postiz-agent]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.