fix(deploy): keep the workspace-id resolver module-private

A mechanical edit stranded an `export` onto `resolveWorkspaceId` and stripped it
from `DeploymentStateRow`. It type-checked because the call sites pass the row
structurally, so nothing caught it.

The export is the part that matters: this helper queries the global pool, so
calling it inside a transaction callback is exactly the nested checkout the
tripwire throws on — and exporting it invited a caller to do that from somewhere
already holding a connection. That widened the surface the previous commit
narrowed by making `materializeDeploymentState` require a `workspaceId`.

`DeploymentStateRow` stays unexported: nothing imports it, and the call sites
satisfy it structurally.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: icecrasher321

apps/sim/lib/workflows/persistence/utils.ts

@@ -145,9 +145,12 @@ export function invalidateDeployedStateCache(deploymentVersionId?: string): void
   deployedStateCache.clear()
 }
 
-export /**
- * Only for entry points that are NOT inside a transaction — it checks out a
- * connection of its own.
+/**
+ * Deliberately module-private: it queries the global pool, so calling it inside
+ * a transaction callback is the nested checkout `packages/db/tx-tripwire.ts`
+ * throws on. Keeping it unexported is what stops a future caller reaching for it
+ * from somewhere that already holds a connection — the same reasoning that made
+ * `materializeDeploymentState` take a `workspaceId` instead of resolving one.
  */
 async function resolveWorkspaceId(workflowId: string, provided?: string): Promise<string> {
   if (provided) return provided