feat: agent executor

[solaris007]

Overview

• The task processor now supports both asynchronous SQS-triggered execution and direct synchronous invocations (e.g., from Step Functions) while keeping the existing handler pipeline intact.
• Brand-profile agents and future “agent” workloads can run via the new path, enabling workflows to wait for results before moving on to Slack notifications or other states.

Motivation

• Agent workflows require deterministic sequencing and access to the agent’s output. Relying solely on SQS meant downstream steps (like Slack notifications) couldn’t see whether the agent succeeded. Direct invocation solves that while maintaining backward compatibility with existing SQS flows.

Key Changes

• Refactored src/index.js so message processing lives in processTask, wrapped twice: once with the existing sqsEventAdapter pipeline, and once without. The exported main auto-detects event shape (Records vs single payload) and routes to the appropriate handler.
• Added a README section describing both invocation modes (SQS and direct) and preserved the Azure env guidance for agent executor users.
• Updated test/index.test.js with a direct invocation scenario to ensure the new path works.
• (Earlier changes retained) — agent executor/slack-notify handlers, brand-profile agent + prompts, registry, unit coverage, integration test, test:brand-profile-it script, README sections for handlers/env vars.

Testing

• npm test
• npm run test:brand-profile-it (with BRAND_PROFILE_IT=1 and Azure env vars) to exercise the direct agent path.

This keeps legacy SQS consumers untouched while enabling Step Functions to call the same Lambda synchronously.

[github-actions]

This PR will trigger a minor release when merged.

[solaris007]

i will have to merge without review due to time pressure (cc @dzehnder for post-factum review)

[solaris007]

🎉 This PR is included in version 1.6.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀