fix(tiktok): correct picture_size_check_failed message and pre-check image sizes

[giladresisi]

What kind of change does this PR introduce?

Bug fix.

Why was this change needed?

A customer created many TikTok carousels through the public API (via an agent). Many, but not all, failed with TikTok's fail_reason: picture_size_check_failed, which we mapped to "Video must be at least 720p, Picture must no exceed 1080p". She resized every image to 941x1672 and the same posts kept failing.

The message was the problem. It invents a photo minimum TikTok does not document, never says which dimension "1080p" refers to, and states a 720p video floor with no basis in the docs. So it pointed her at the wrong thing entirely.

The actual cause: her failing carousels each contained at least one 1086x1448 image - 6px over the 1080 limit on the shorter side - mixed in among valid 941x1672 ones. A single oversized image fails the whole carousel, and TikTok never reports which image failed, so the generic error gave her no way to find it. Two failed posts were inspected image by image; both contained 1086x1448 stragglers, while every image in a successful post was within 1080 on the shorter side.

This PR does two things:

1. Corrects the error message to describe the real limits.
2. Adds a pre-flight image-size check in checkValidity that names the offending image, so the problem surfaces at save time instead of hours later at publish. It mirrors the existing Pinterest check in pinterest.provider.ts and reuses the getImageDimensions helper on SocialAbstract.

Other information:

Verified against the real TikTok API on a connected channel. Media was uploaded through the public API rather than the UI, because UI uploads pass through Transloadit and get re-encoded (a 480x640 clip becomes 720x960), while API uploads are stored as-is and reach TikTok at their original dimensions. That asymmetry is deliberate and is left untouched here - it is also why this only ever bit an API user.

video sent	result
480x640	PUBLISHED - disproves the "at least 720p" claim
320x320	FAILED with picture_size_check_failed - confirms the documented 360 floor
5000x5000	PUBLISHED - TikTok does not enforce its documented 4096 maximum

Because of the third row, the new message deliberately omits the 4096 ceiling and claims only what was observed: images up to 1080px on the shorter side, videos at least 360px on both sides. The 320x320 failure was confirmed end-to-end through the new mapping, so the corrected string is what a user actually sees.

Existing scheduled posts: checkValidity runs only on create/update (posts.service.ts validatePosts, reached from the dashboard, the public API and the agent tool) and is not part of the publish path. Already-scheduled carousels containing an oversized image are therefore not re-validated and will still fail at publish - but now with the corrected message rather than the misleading one. The pre-flight check protects newly created and edited posts only.

Not covered: videos are not pre-checked. There is no ffmpeg dependency on the server (the browser-side duration checks were dropped for this reason in 1b53973 when validation moved server-side), so video dimensions still only surface at publish, through the corrected message.

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.

[giladresisi]

Good catch, this is a real regression. changeState only wrote the error column when it had a curated message, so a post that failed once with a curated bad_body message and then failed again for an uncurated reason kept the old value and the tooltip showed the earlier unrelated error.

It was flagged here by accident though: this branch was mistakenly created off fix/calendar-mapped-error-tooltip instead of main, so posts.repository.ts was never part of this PR. That has been fixed, PR 1875 is now rebased onto main and contains only the TikTok provider change.

The fix is in PR 1868, which owns that code: commit e0aa9cb overwrites the error column on every failure, so uncurated failures clear it and the tooltip falls back to the generic text. The full failure still goes to the Errors table.