feat(local-elasticmq): Add ElasticMQ-backed local queue emulator

[mnzsss]

Summary

This PR adds a new @ez4/local-elasticmq provider that lets the local queue emulator run on top of ElasticMQ instead of the in-memory implementation. It also refactors @ez4/local-queue so the emulator can plug in an external client through a trigger, keeping the in-memory mode as the default fallback.

The new package is opt-in: install it next to @ez4/local-queue and local queues talk to a real SQS-compatible service. Don't install it and nothing changes — the in-memory emulator keeps working exactly as before.

Why

The in-memory emulator is great for fast tests but it diverges from how SQS actually behaves. FIFO ordering, deduplication windows, visibility timeouts, DLQ redrive — those are easy to get subtly wrong when the local implementation doesn't share the same semantics as the deployed one.

ElasticMQ ships a real SQS-compatible queue server, so pointing the emulator at it removes that gap. Local development and CI exercise the same wire protocol, the same FIFO/dedup rules, and the same client SDK the AWS provider uses in production. Bugs that only show up against real SQS now also show up locally.

The change is structured so adopting ElasticMQ stays a choice. Projects that don't need SQS-level fidelity keep the zero-setup in-memory mode. Projects that do install one extra package and add a couple of lines of localOptions.

What changed

@ez4/local-elasticmq (new package)

• SQS SDK client factory with send/receive support and FIFO/fair-mode awareness
• Queue topology management (standard, FIFO, DLQ wiring, purge)
• Poller lifecycle that dispatches received messages to the registered subscribers
• Options resolver with config validation for localOptions.queue (host/port/endpoint)
• Registers emulator:getClient and emulator:getServices triggers so @ez4/local-queue picks it up automatically when present
• Unit tests covering options, client, topology, and poller

@ez4/local-queue

• Replace direct in-memory registration with registerQueueEmulator, which first asks for an external client via the emulator:getClient trigger and falls back to in-memory when none is registered
• Move the shared message dispatch lifecycle (processQueueMessage, formerly processLambdaMessage) into @ez4/local-common so both emulators reuse it
• Re-export the renamed handler from @ez4/local-queue for backwards compatibility
• README documents the two emulator modes

@ez4/local-common

• New shared processQueueMessage handler (begin/ready/done/error/end lifecycle, validation, scoped runtime)
• Test coverage for the shared dispatch path

Examples and infra

• examples/hello-local-elasticmq: standard, FIFO, and FIFO-with-deduplication queue configurations against the ElasticMQ emulator
• docker-compose.yml: add the softwaremill/elasticmq-native service on port 9324
• Register @ez4/local-elasticmq in the root workspace

Behavior

Before:

• Local queues always ran on the in-memory emulator
• FIFO ordering, deduplication, and DLQ behavior could drift from real SQS without anyone noticing locally
• Tests that wanted SQS semantics had to either deploy or stand up their own external setup

After:

• @ez4/local-queue keeps the in-memory emulator as default
• Installing @ez4/local-elasticmq and configuring localOptions.queue switches local queues to ElasticMQ transparently
• The same client SDK and the same queue semantics are used locally and in production
• No code changes required in services or subscriptions to opt in