Implement orderingKey option in PostgresMessageQueue for ordered message
delivery:

- Add ordering_key column to the message queue table schema
- Store ordering key when enqueuing messages
- Modify listen() to skip messages with ordering keys currently being
  processed, ensuring messages with the same key are processed sequentially
- Enable testOrderingKey in PostgresMessageQueue tests
- Update documentation table to show PostgresMessageQueue supports
  ordering keys

This allows ensuring related messages are processed in order, such as
processing Delete activities after Create activities for the same object.

fedify-dev#538

Co-Authored-By: Claude <noreply@anthropic.com>

Implement ordering key support for SqliteMessageQueue to ensure messages with
the same ordering key are processed sequentially, while messages with different
keys can be processed in parallel. This helps prevent race conditions when
processing related activities.

Changes:

- Added ordering_key column to the message queue table schema
- Modified enqueue() and enqueueMany() to store the ordering key
- Modified listen() to track which ordering keys are being processed and
  skip messages with locked ordering keys
- Enabled testOrderingKey: true in the test suite
- Updated docs/manual/mq.md implementation support table
- Updated CHANGES.md

fedify-dev#538

Co-Authored-By: Claude <noreply@anthropic.com>

To ensure messages with the same ordering key are processed sequentially,
RedisMessageQueue now tracks which keys are being processed and skips
messages with locked keys when polling.

fedify-dev#538

Co-Authored-By: Claude <noreply@anthropic.com>

Implement ordering key support for AmqpMessageQueue using RabbitMQ's
rabbitmq_consistent_hash_exchange plugin.  Messages with the same ordering
key are routed to the same partition queue, ensuring FIFO processing.

The implementation:

- Uses x-consistent-hash exchange type for routing by ordering key
- Creates configurable number of partition queues with x-single-active-consumer
- Supports delayed messages with ordering keys via dead-letter routing
- Requires rabbitmq_consistent_hash_exchange plugin (Tier 1, ships with
  RabbitMQ but not enabled by default)

fedify-dev#538

Co-Authored-By: Claude <noreply@anthropic.com>

Configure CI workflow to enable the rabbitmq_consistent_hash_exchange plugin
so that AmqpMessageQueue ordering key tests can run.  Changes:

- Add health check options to RabbitMQ service containers
- Add step to enable plugin via docker exec before running tests
- Set AMQP_ORDERING_TEST=true environment variable for all test jobs

Co-Authored-By: Claude <noreply@anthropic.com>

Co-Authored-By: Claude <noreply@anthropic.com>

Replace the in-memory processingKeys Set with PostgreSQL advisory locks
for proper distributed ordering key support across multiple workers.

The previous implementation only tracked processing keys within a single
process, which meant messages with the same ordering key could be
processed concurrently by different worker instances.

Now uses pg_try_advisory_lock(hashtext(tableName), hashtext(orderingKey))
to acquire distributed locks before processing messages. The lock is
released with pg_advisory_unlock after the message handler completes.

This ensures that messages with the same ordering key are processed
sequentially even in a distributed multi-worker environment.

Co-Authored-By: Claude <noreply@anthropic.com>

…eMany()

Add JSDoc to explain how orderingKey behaves with and without delay:
- Without delay: routes through consistent hash exchange directly
- With delay: routes through delay queue, then to consistent hash exchange

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

Replace `any` type with `ConsumeMessage | null` from amqplib for
the msg parameter in the messageHandler callback.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

Replace `any` type with `WrappedMessage | unknown` for the rawMessage
parameter in the wrappedHandler callback.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

Add ALTER TABLE statement to add the ordering_key column if it doesn't
exist. This handles existing deployments that already have the queue
table without the ordering_key column, preventing insert failures when
upgrading to a version with ordering key support.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

Update the JSDoc comment to clarify that when shouldProcess is false,
the caller is responsible for re-enqueuing or retrying, as the
processMessage() method does not automatically re-enqueue the message.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

The AmqpOrderingOptions interface was introduced with ordering key support,
which is a Fedify 2.0.0 feature.  The @SInCE tag incorrectly said 0.4.0.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

When multiple messages are enqueued in the same millisecond,
#getMonotonicTimestamp() adds fractional milliseconds (0.001 per message)
to maintain ordering.  This caused the pub/sub notification check
`ts <= now` to fail for the 2nd+ message since their timestamps would be
`now + 0.001` or higher.

Changed to use `baseTs <= now` instead, so all messages enqueued for
immediate processing trigger the notification regardless of the monotonic
sequence number added.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

When a message has an orderingKey but delay is explicitly set to
Temporal.Duration.from({ seconds: 0 }), the delay value is 0 (not null).
The previous condition `delay == null` would skip the ordering path,
sending such messages directly to the main queue instead of the
consistent hash exchange.

Changed the condition to `delay == null || delay <= 0` so zero-delay
messages with ordering keys are correctly routed through the ordering
exchange, consistent with how the delayed queue path already handles this.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

The previous implementation re-enqueued messages with a 100ms delay when
the ordering key lock was held.  This could break FIFO order because:

1. Message A (key: "x") is being processed
2. Message B (key: "x") arrives, sees lock, re-enqueues with 100ms delay
3. Message C (key: "x") arrives, sees lock, re-enqueues with 100ms delay
4. Message A finishes
5. C might be processed before B depending on re-enqueue timing

Changed to use a sleep/retry loop that keeps the handler blocked until the
lock can be acquired.  This preserves the original message ordering since
each handler waits its turn rather than re-joining the queue.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

ParallelMessageQueue can only detect ordering keys from messages that use
the wrapper format with `__fedify_ordering_key__` property.  Currently
only DenoKvMessageQueue and WorkersMessageQueue use this format.

Other queue implementations (InProcessMessageQueue, RedisMessageQueue,
PostgresMessageQueue, SqliteMessageQueue, AmqpMessageQueue) deliver raw
payloads, so ParallelMessageQueue cannot detect their ordering keys.
Those implementations handle ordering guarantees internally instead.

Added documentation to both the class-level JSDoc and the
#extractOrderingKey method to clarify this limitation.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>

Updated the note about ParallelMessageQueue ordering to clarify that it
only detects ordering keys from queue implementations that use wrapper
format (DenoKvMessageQueue and WorkersMessageQueue).  For other
implementations, ordering is handled internally by the queue itself.

fedify-dev#540 (comment)

Co-Authored-By: Claude <noreply@anthropic.com>