fix(slack): bump command processor memory to 512 MB (#233)

Closes #231.

The command processor was running at the CDK default of 128 MB and
OOMing during module init. Symptom: @bgagent mentions in Slack got the
👀 reaction (receiver acked the event) but never the follow-up
acknowledgement — the processor crashed before doing anything.

CloudWatch logs:
  INIT_REPORT ... Phase: init  Status: error  Error Type: Runtime.OutOfMemory
  REPORT ... Memory Size: 128 MB  Max Memory Used: 127 MB

Cause: createTaskCore's transitive dependency graph (Cedar engine,
attachment-screening, related deps) grew past the 128 MB module-init
ceiling. The Slack processor imports createTaskCore so it loads the
whole graph even on hot paths that never use attachments.

The Linear webhook processor hit the same pattern earlier and was
bumped in d843540. Slack's processor was never explicitly sized so
it stayed at the default until the bundle finally crossed 128 MB.

Followup #232 tracks the deeper fix (lazy-load attachment/Cedar deps
in createTaskCore so processors don't need 512 MB).

Author: isadeks

cdk/src/constructs/slack-integration.ts

@@ -238,12 +238,17 @@ export class SlackIntegration extends Construct {
     }));
 
     // --- Slash Command Processor (async worker) ---
+    // Memory bumped from default 128 MB → 512 MB after module-init OOM
+    // surfaced in dev. Bundle grew past the 128 MB cap once createTaskCore's
+    // transitive dependency graph (Cedar, attachment-screening) imported
+    // here through the shared task-creation path.
     const commandProcessorFn = new lambda.NodejsFunction(this, 'CommandProcessorFn', {
       entry: path.join(handlersDir, 'slack-command-processor.ts'),
       handler: 'handler',
       runtime: Runtime.NODEJS_24_X,
       architecture: Architecture.ARM_64,
       timeout: Duration.seconds(30),
+      memorySize: 512,
       environment: {
         ...createTaskEnv,
         SLACK_USER_MAPPING_TABLE_NAME: this.userMappingTable.tableName,