chore: sync with upstream Postiz (2026-09-22 evening)

[JOY (JOY)]

What kind of change does this PR introduce?

CI/CD / Upstream sync. Manually completed sync merging upstream gitroomhq/postiz-app main (75 commits, head 4c33d52) into dev: provider error-mapping fixes (dribbble, X, lemmy, VK), X unauthorized-refresh-token fix, YouTube clipping workflow stabilization, Mastra/MCP updates.

Five conflicts resolved by hand:

• .env.example - kept the fork Temporal section, accepted upstream additions
• libraries/nestjs-libraries/src/chat/load.tools.service.ts + start.mcp.ts - kept fork branded tool aliases (crove_post_*), accepted upstream clipping tool additions
• libraries/nestjs-libraries/src/database/prisma/organizations/organization.repository.ts - kept BOTH imports (fork isCroveBillingGated + upstream makeSecureId)
• libraries/nestjs-libraries/src/integrations/social/reddit.provider.ts - kept the fork's Reddit OAuth broker flow entirely (upstream's direct-Reddit change rejected); restored the makeId import the merge had dropped
• apps/frontend/src/components/public-api/public.component.tsx + onboarding/onboarding.modal.tsx - kept fork's brandConfig fail-closed connector gating, REMOVED the upstream mcpConnectorUrls table (hardcoded claude.ai/directory/postiz, chatgpt plugins, cursor marketplace, x.ai bot URLs - upstream cloud routing, flagged by branding guard)

Why was this change needed?

Keep the upstream corridor current: 75 commits of provider fixes, clipping workflow stabilization and security hardening flow in small reviewable increments (per ADR-0001).

Technical Details & Scope

• Merge commit ff8e69a + follow-up resolution commits on the branch
• Branding guard passes clean: 0 strict leaks (the mcpConnectorUrls upstream URL table was removed as part of the resolution)
• Backend nest build verified green locally (0 TS errors)

Verification & Testing

• Zero conflict markers repo-wide (git grep)
• pnpm run build:backend: compiles clean
• branding-guard.ts: PASS (0 strict leaks)
• CI on this PR runs build.yml (bootstrap suites + full build) + branding-guard

QA

1. Open the PR Files changed - confirm the 5 resolved files keep fork branding/behavior (branded tool aliases, broker reddit flow, fail-closed connector cards)
2. CI: build.yml green (bootstrap suites 53 passing, full build)
3. branding-guard.yml green on this PR
4. After deploy: schedule a post on one connected channel on beta to confirm the provider error-mapping changes did not regress posting

Checklist:

• My code follows the project's code style and architectural conventions.
• Local verification done: backend build clean before push.
• Branding guard validated locally (PASS, 0 strict leaks) + CI gate.
• Tests - CI bootstrap suites are the gate.
• Documentation n/a (sync).
• No secrets or sensitive credentials are included in this PR.
• I have filled in the QA / Verification section above with real steps to verify this change.

[dos]

⏱️ Code Review completed (44 files · 102,084 chars · 3 PR unit(s))

ℹ️ Full-Context Analysis: Analyzed all changed files in a unified context pass to preserve cross-file type definitions, imports, and caller contracts. Deducted 3 PR units.
⚠️ PR diff exceeded maximum review ceiling (3 batches / ~90,000 chars) - lower-priority files were skipped.

⏱️ Adversarial Review completed (Model: qwen3.8-27b)

🔍 Verified Adversarial Review Findings

📋 Findings Summary (1 inline finding)

• 🟡 IMPORTANT libraries/nestjs-libraries/src/integrations/social/hashnode.provider.ts:177-180: Tag mapping produces undefined slug for unknown tags (💡 1-click suggestion on diff)

💡 1-Click Suggestions Ready: Go to the Files changed tab to review and apply 1 suggestion directly with 1-click commit.

🛡️ Dismissed Claims

• Hashnode cover image field change (coverImage vs coverImageOptions): The diff changes the endpoint from gql.hashnode.com to gql-beta.hashnode.com. The gql-beta endpoint is the newer API version which uses the coverImage string field directly, whereas the older gql endpoint used coverImageOptions. Since the endpoint and the field name are changed together to match the new API contract, this is a valid migration, not a bug.

[dos]

🟡 IMPORTANT: Tag mapping produces undefined slug for unknown tags

Failure Trace:

1. User selects a tag in the UI. The tag.value is an objectID string.
   2. The code executes tags.find((t) => t.objectID === tag.value)?.slug.
   3. If tag.value does not match any objectID in the static tags array (e.g., due to a mismatch, a new tag added to Hashnode not yet in the local list, or a typo), find returns undefined.
   4. The resulting object is { slug: undefined }.
   5. This object is included in the tags array of the GraphQL mutation payload.
   6. When sent to the Hashnode API, the undefined value is either stripped (resulting in an empty object {} which may fail validation) or causes a GraphQL validation error because slug is required. This breaks post creation or results in tags being silently dropped.

Suggested change

	? { originalArticleURL: settings.canonical }
	: {}),
	contentMarkdown: postDetails?.[0].message,
	tags: settings.tags.map((tag: any) => ({ id: tag.value })),
	tags: settings.tags.map((tag: any) => ({
	tags: settings.tags
	.map((tag: any) => ({
	slug: tags.find((t) => t.objectID === tag.value)?.slug,
	}))
	.filter((t) => t.slug),

[gemini-code-assist]

Code Review

This pull request introduces several enhancements, including the integration of clipping tools, the addition of a comprehensive Postiz Cloud vs. Open-source comparison in the README, and the implementation of a cryptographically secure makeSecureId utility to replace makeId for sensitive tokens and credentials across multiple social providers. It also strengthens error handling for various social integrations (such as Facebook, Lemmy, Slack, and X), refines tag deletion in the database, and adds support for both .mov and .mp4 video uploads. The code review feedback highlights three key areas for improvement: first, the page query parameter in public.integrations.controller.ts should be explicitly parsed as an integer using NestJS pipes to prevent runtime type mismatches; second, in reddit.provider.ts, a safety check should be added to ensure about.data is defined before accessing its nested properties to avoid potential crashes; and third, in hashnode.provider.ts, undefined slugs should be filtered out during tag mapping to prevent sending empty objects that would fail Hashnode's GraphQL validation.

[gemini-code-assist]

The page query parameter is typed as number, but without a transformation pipe or explicit parsing, NestJS will receive it as a string at runtime (or undefined if not provided). This can cause runtime errors or unexpected behavior (like NaN offset calculations) when passed to the database service. Consider using ParseIntPipe along with DefaultValuePipe to ensure it is always a valid integer. Note: You will need to import ParseIntPipe and DefaultValuePipe from @nestjs/common.

Suggested change

	@Query('page') page: number
	@Query('page', new DefaultValuePipe(1), ParseIntPipe) page: number

[gemini-code-assist]

If the about response is returned but the data property is missing or undefined, accessing about.data.subreddit_type will throw a TypeError: Cannot read properties of undefined (reading 'subreddit_type') and crash the execution. You should safely guard against a missing data object before accessing its nested properties.

Suggested change

	if (
	about?.kind !== 't5' ||
	about.data.subreddit_type !== 'public' ||
	about.data.submission_type === 'image'
	) {
	if (
	about?.kind !== 't5' ||
	!about?.data ||
	about.data.subreddit_type !== 'public' ||
	about.data.submission_type === 'image'
	) {

[gemini-code-assist]

If tags.find returns undefined (i.e., a tag value is not found in the predefined tags array), mapping it directly will result in { slug: undefined }. When serialized to JSON, this becomes {}. Hashnode's GraphQL API expects a non-empty slug or id for each tag input, so sending an empty object will trigger a validation error. It is safer to filter out any undefined slugs before mapping them.

Suggested change

	tags: settings.tags.map((tag: any) => ({
	slug: tags.find((t) => t.objectID === tag.value)?.slug,
	})),
	tags: settings.tags
	.map((tag: any) => tags.find((t) => t.objectID === tag.value)?.slug)
	.filter((slug): slug is string => !!slug)
	.map((slug) => ({ slug })),

[dos]

⏱️ Code Review completed (44 files · 101,935 chars · 3 PR unit(s))

ℹ️ Full-Context Analysis: Analyzed all changed files in a unified context pass to preserve cross-file type definitions, imports, and caller contracts. Deducted 3 PR units.
⚠️ PR diff exceeded maximum review ceiling (3 batches / ~90,000 chars) - lower-priority files were skipped.

⏱️ Adversarial Review completed (Model: qwen3.8-27b)

🔍 Verified Adversarial Review Findings

📋 Findings Summary (1 inline finding)

• 🟡 IMPORTANT libraries/nestjs-libraries/src/integrations/social/hashnode.provider.ts:180: Unsafe tag mapping produces undefined slug (💡 1-click suggestion on diff)

💡 1-Click Suggestions Ready: Go to the Files changed tab to review and apply 1 suggestion directly with 1-click commit.

🛡️ Dismissed Claims

• Hashnode cover image field name change: The change from coverImageOptions: { coverImageURL: ... } to coverImage: ... is a deliberate API contract update. The diff also updates the endpoint from gql.hashnode.com to gql-beta.hashnode.com, indicating a migration to a new API version where the schema has changed. Without evidence that the new endpoint still expects the old field name, this is not a bug but an intentional adaptation to the new API.

[dos]

🟡 IMPORTANT: Unsafe tag mapping produces undefined slug

Failure Trace:

1. User creates a post with a tag where tag.value is an ID not present in the static tags array (e.g., a new tag added to Hashnode after the static list was generated, or a mismatch in ID format).
   2. tags.find((t) => t.objectID === tag.value) returns undefined.
   3. ?.slug evaluates to undefined.
   4. The resulting object is { slug: undefined }.
   5. When jsonToGraphQLQuery constructs the mutation, it serializes this as { slug: null } or omits the field depending on configuration, but typically sends null for undefined values in object literals.
   6. The Hashnode GraphQL API rejects the mutation with a validation error (e.g., "Field slug of type String! was not provided") or silently fails to apply the tag, whereas the previous code sent the raw ID which might have been handled differently or failed more explicitly.

Suggested change

	tags: settings.tags.map((tag: any) => ({
	tags: settings.tags
	.map((tag: any) => {
	const found = tags.find((t) => t.objectID === tag.value);
	return found ? { slug: found.slug } : null;
	})
	.filter(Boolean),