improvement(background): right-size the two knowledge task machines

Both knowledge tasks reserved machine presets well above their measured
ceilings. Sized each from production telemetry on both memory and CPU:

- knowledge-connector-sync: large-2x -> large-1x. Peak sampled RSS 2.6 GB
  and peak 1.4 vCPU, so 8 GB/4 vCPU keeps ~3x memory and ~2.8x CPU headroom
  against a preset that reserved 16 GB.
- knowledge-process-document: large-1x -> medium-2x. Peak sampled RSS 902 MB
  and peak 1.2 vCPU, with no document exceeding 2 GB, so 4 GB/2 vCPU keeps
  ~4x memory and ~1.7x CPU headroom.

CPU figures are core-normalized (OTel process.cpu.utilization divides by
cores available), so neither task loses headroom it was actually using and
neither can be throttled by the smaller preset.

No retry or concurrency semantics change.

Author: waleedlatif1

apps/sim/background/knowledge-connector-sync.ts

@@ -98,7 +98,14 @@ export async function executeConnectorSyncJob(payload: unknown) {
 export const knowledgeConnectorSync = task({
   id: 'knowledge-connector-sync',
   maxDuration: CONNECTOR_SYNC_MAX_DURATION_SECONDS,
-  machine: 'large-2x',
+  /**
+   * Sized from production telemetry: peak sampled RSS 2.6 GB and peak 1.4 vCPU,
+   * so `large-1x` holds ~3x memory and ~2.8x CPU headroom. No `outOfMemory`
+   * escalation: an OOM is a SIGKILL, so the run never reaches the terminal
+   * write that clears `syncLockToken`, and the escalated attempt would find the
+   * row still `syncing` and skip. The stale-lock reaper owns that recovery.
+   */
+  machine: 'large-1x',
   retry: {
     maxAttempts: 3,
     factor: 2,

apps/sim/background/knowledge-processing.ts

@@ -135,7 +135,13 @@ export async function runDocumentProcessing(
 export const processDocument = task({
   id: 'knowledge-process-document',
   maxDuration: envNumber(env.KB_CONFIG_MAX_DURATION, 600),
-  machine: 'large-1x', // 4 vCPU, 8GB RAM - needed for large PDF processing
+  /**
+   * Sized from production telemetry: peak sampled RSS 902 MB and peak 1.2 vCPU
+   * across a corpus where no document exceeded 2 GB, so `medium-2x` holds ~4x
+   * memory and ~1.7x CPU headroom over the observed worst case. The prior
+   * `large-1x` reserved 8 GB against a worst case using an eighth of it.
+   */
+  machine: 'medium-2x',
   retry: {
     maxAttempts: envNumber(env.KB_CONFIG_MAX_ATTEMPTS, 3),
     factor: envNumber(env.KB_CONFIG_RETRY_FACTOR, 2),