fix: direct invoke

[solaris007]

Overview

• Fixed the task processor’s dual-mode entrypoint so it correctly distinguishes between SQS-triggered events and direct invocations (e.g., from Step Functions) even when the Lambda context contains invocation.event.Records.
• Added a regression test to ensure direct payloads are processed through the synchronous path regardless of context metadata.

Motivation / Context

• When the new agent Step Function invoked the task processor directly, the Lambda still saw context.invocation.event.Records (populated by the runtime), so we mistakenly treated the request as an SQS batch and returned the “event does not contain any records” warning—preventing agent execution and Slack notifications.
• Direct invocation must remain synchronous so workflows can read agent results and handle Slack steps downstream.

Key Changes

• src/index.js: simplified isSqsEvent to check only the incoming event (event.Records), ensuring real SQS batches continue to use the adapter while direct payloads skip it.
• test/index.test.js: added a test case covering the scenario where the event is direct but the context still includes invocation.event.Records, confirming we pick the direct path.

Testing

• npm test
• Verified Step Function direct invokes now execute without warnings and produce agent results/slack notifications.

[github-actions]

This PR will trigger a patch release when merged.

[solaris007]

have to merge due to time pressure, post-merge review @dzehnder

[solaris007]

🎉 This PR is included in version 1.6.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀