triggers: HTTP, object-store and cron as enqueue sources

Every job enters FlexiQ by someone calling enqueue. The server has no way to be the thing
something else calls.

That leaves the most common integrations to the user: an HTTP endpoint that receives a webhook
and enqueues, a function that fires on an object-store upload and enqueues, a cron container
whose only job is to enqueue. Each is a small service the user must build, deploy and operate,
and each is the same service every time.

Add triggers as a first-class concept:

• HTTP trigger — a URL that maps an inbound request to an enqueue. Payload mapping, a
  shared-secret or signature check, and per-trigger rate limiting. This is the on-ramp for
  Stripe, GitHub, Twilio and every other webhook source.
• Object-store trigger — an S3/GCS/Azure event maps to an enqueue. Mostly a payload mapping
  plus the eventing platform's own auth.
• Cron trigger — periodic tasks exist in the core already. What is missing is defining one
  over the network rather than in application code, which the admin service (#836) covers.

Constraints:

• a trigger is a configuration object, not code. It maps an inbound payload to a task name
  and arguments. Anything more expressive is a scripting engine and is out of scope.
• untrusted input reaches enqueue directly, so a trigger is bounded by the finer token scopes in
  #839: a trigger enqueues one task, to one queue, in one namespace.
• rate limiting per trigger is mandatory, not optional. A public URL that enqueues is a public
  URL that fills a queue.

Start by tracing the existing enqueue path and reviewing how periodic tasks are handled in the core. Then read the related admin service issue (#836) and token-scope issue (#839). Done means defining bounded HTTP, object-store, and cron trigger configuration with payload mapping, required authentication or platform authorization, and per-trigger rate limiting.