[Embed] Require specific piece(s) present in a flow before publish

Context

Embedders want Activepieces positioned as their workflow layer, not a generic Make/Zapier surface. They need a guarantee that every published flow involves their own embedded piece — as the trigger (most common) or anywhere as an action — otherwise the flow shouldn't be publishable. The narrower "lock the trigger slot to our piece" ask is a subset of this; the real requirement is "our piece must participate before publish."

Ref: Pylon #4990

Current behavior (verified in code)

• Piece availability is filtered via the embed provision token / project policy: PiecesFilterType is NONE | ALLOWED only (packages/shared/src/lib/management/project/project.ts). ALLOWED + tags restricts which pieces appear in the menu, trigger picker included.
• That filter governs the menu, not flow composition. If several trigger-capable pieces are allowed, a user can start with any of them, and a flow can be built and published without the embedder's piece appearing at all.
• Publish/lock validation (packages/server/api/src/app/flows/flow-version/flow-version-validator-util.ts) only checks per-step prop validity — piece/trigger/action existence, required inputs, auth. There is no policy hook that asserts a specific piece must be present in the flow graph. EMPTY trigger is rejected; "no required piece" is not.
• Net: no current mechanism enforces presence of a designated piece. The only workaround is external — a webhook-on-publish that inspects the flow and unpublishes if the piece is missing — which is poor UX: the flow shows as published before being silently reverted.

Proposed

Add an embed/platform-level policy: one or more required pieces that must appear in a flow (as trigger OR action) for publish to succeed.

• Config surface: extend the provision token / project policy alongside piecesFilterType — e.g. a requiredPieces list (piece names).
• Enforcement: at LOCK_AND_PUBLISH, validate the flow graph contains at least one step (trigger or action) matching a required piece. If absent, block the publish and return a clear, surfaceable error — not a silent post-publish revert.
• Builder UX: reflect the unmet requirement before the user attempts publish (disabled/annotated publish button + reason), so it's not a surprise at click time.
• Default: empty requiredPieces → no enforcement, existing behavior unchanged.

Out of scope (v1)

• Pinning the trigger slot to one specific piece (possible follow-up if "present anywhere" proves insufficient — current signal is "involved at some level," which presence-anywhere satisfies).
• Quantity/position constraints (e.g. "must be the first step", "exactly once").
• Runtime enforcement on already-published flows imported via other paths (compare activepieces/activepieces#8071).

Relates to activepieces/activepieces#13525 (per-project active-flow limits) — same embed-governance theme.