Implement Azure Functions Queue Trigger Handler Registration

[nnoce14]

Summary

Add first-class Azure Functions queue trigger handler registration to the Cellix API bootstrap flow.

Cellix already supports registering Azure Functions HTTP handlers. Queue trigger support should follow the same general pattern, with any obvious refinements applied in a way that can later generalize across all Azure Functions handler types.

For now, implement this in @apps/api/src/cellix.ts. This will eventually be moved into a Cellix framework package such as @cellix/core.

This task should preferably start from PR #264 / branch issue263/queue-storage-service, since that work already adds the queue storage service and application queue registration pieces this task should build on:

#264

Goals

• Add Azure Functions queue trigger handler registration to the Cellix bootstrap flow.
• Follow the existing Azure Functions HTTP handler registration pattern where reasonable.
• Refine shared handler registration concepts that should apply to HTTP and queue handlers.
• Add one trivial Owner Community queue trigger example to prove the pattern works end-to-end.
• Keep the implementation app-local in @apps/api/src/cellix.ts for now.

Example: Community Update Queue

Add a trivial storage queue handler for a community-update queue in the sample Owner Community application.

The queue message should include:

• communityId
• optional community settings/model fields to update

Expected behavior:

• Parse and validate the queue message.
• Look up the community by communityId.
• If the community exists:
  • apply the provided update fields
  • persist the updated community record
• If the community does not exist:
  • log an error
  • take no database action
  • do not crash the host for this expected miss case

Implementation Notes

• Build on the queue storage/application queue registration work from PR feat(queue-storage): implement @cellix/service-queue-storage and @ocom/service-queue-storage (#263) #264.
• Reuse the existing Cellix application context and service initialization pattern.
• Queue handlers should receive only the scoped context they need, similar to the intended HTTP handler pattern.
• Avoid coupling the queue handler registration API to the community-update example.
• Prefer a shape that can later generalize to HTTP triggers, queue triggers, timer triggers, and other Azure Functions trigger types.
• Keep the bootstrap code clear enough for junior developers, agents, and external contributors to follow.

A possible shape is:

cellix.registerAzureFunctionHttpHandler(...)

cellix.registerAzureFunctionQueueHandler(...)

The exact API can vary, but queue handler registration should account for:

• queue name
• message schema / typed message contract
• handler callback
• scoped context requirements
• logging and error behavior

Acceptance Criteria

• Azure Functions queue trigger handlers can be registered through the Cellix API bootstrap flow.
• Existing HTTP handler registration continues to work unchanged.
• Shared concepts between HTTP and queue handler registration are cleaned up where practical.
• A community-update queue is registered in the Owner Community sample app.
• A queue-triggered handler processes community-update messages.
• Valid messages update an existing community record with the provided fields.
• Messages for missing communities log an error and take no database action.
• Invalid messages fail predictably through validation/error handling.
• Local development works against Azurite using the queue storage service from PR feat(queue-storage): implement @cellix/service-queue-storage and @ocom/service-queue-storage (#263) #264.
• Tests or local verification steps prove the queue handler path works end-to-end.
• Implementation remains in @apps/api/src/cellix.ts for now, with clear seams for later extraction into @cellix/core.

Out of Scope

• Moving Cellix bootstrap code into @cellix/core.
• Building a full queue worker framework.
• Supporting every Azure Functions trigger type.
• Complex retry/poison-queue policy design beyond what already exists in the queue storage service branch.
• Production-grade community update behavior beyond the trivial proof-of-pattern.