fix: unlock Community deploy policy hard-blocking (#1643)

Remove the leftover paid-only blockingEnabled switch so enabled
block-on-deploy policies enforce on every tier, matching the
documented every-tier security surface. Existing Community policies
begin blocking immediately with no migration.

backend/src/services/PolicyEnforcement.ts

@@ -53,11 +53,6 @@ export interface PolicyViolation {
 export interface PolicyEnforcementOptions {
     bypass: boolean;
     actor: string;
-    /**
-     * Paid-tier deploy enforcement switch. Community keeps policies as
-     * evaluation-only and must not block compose starts.
-     */
-    blockingEnabled?: boolean;
     ip?: string;
     /** HTTP method of the originating request; used for audit attribution. */
     auditMethod?: string;
@@ -283,10 +278,6 @@ export async function enforcePolicyPreDeploy(
         return { ok: true, bypassed: false, policy: policy ?? undefined, violations: [] };
     }
 
-    if (opts.blockingEnabled === false) {
-        return { ok: true, bypassed: false, policy, violations: [] };
-    }
-
     const svc = TrivyService.getInstance();
     if (!svc.isTrivyAvailable()) {
         notifyTrivyMissingOnce(nodeId, stackName);

backend/src/services/SchedulerService.ts

@@ -184,8 +184,7 @@ export class SchedulerService {
      * and the offending images, then throw so the caller records the outcome:
      * the auto-update loop catches per stack and continues the rest of the run,
      * while a single-stack auto-start surfaces as a task failure. The gate
-     * fails open when Trivy is missing and is evaluation-only when the node's
-     * local tier is unpaid.
+     * fails open when Trivy is missing.
      */
     private async enforceSchedulerPolicyGate(
         stackName: string,