Add helix-shared-queue-sqs backend package (BatchedQueueClient successor)

[tripodsan]

Why

Concrete SQS backend for the helix-shared-queue base package (#1269), intended as a successor to BatchedQueueClient (@adobe/helix-admin-support) that other services can adopt without depending on a hand-rolled local abstraction.

Scope

• QueueSqs extends Queue, pre-wiring a backendFactory exactly like StorageS3.fromContext:

  export class QueueSqs extends Queue {
    static fromContext(context, opts = {}) {
      return super.fromContext(context, {
        backendFactory: createDefaultBackendFactory(context.env, { log: context.log }),
        ...opts,
      });
    }
  }

• SqsQueueBackend — behavior-preserving port of BatchedQueueClient:
  • sendBatch: pack messages into ≤10-entry/≤256KB SendMessageBatchCommand batches (SQS API limits).
  • Single-oversized-message spill to blob storage via an injected Storage/Bucket (see Add helix-shared-queue base package (pluggable queue abstraction) #1269) instead of a hardcoded S3Client.
  • receiveBatch/deleteBatch: port of BatchedQueueClient.receive()/delete() long-poll + batch-delete.
  • Drop BatchedQueueClient's "whole batch failed -> store to S3 as undeliverable" fallback unless usage data shows it's actually relied upon; log + rethrow instead, consistent with how current call sites don't catch .send() errors.
• Queue naming/addressing (region/account-derived SQS URLs) is internal to this backend, not exposed to callers as a URL — callers pass a logical queue name.

Acceptance

• Test suite mirrors helix-shared-storage-s3's conventions, covering batching, spill, receive, delete against nock'd SQS endpoints.
• Consumers (e.g. helix-api-service) can adopt this via a one-line import swap (import { Queue } from '@adobe/helix-shared-queue' -> import { QueueSqs as Queue } from '@adobe/helix-shared-queue-sqs'), no call-site logic changes beyond that swap.

Depends on: #1269