Wire plugin job dispatch bridge (host ABI + WASM handler)

[tayebmokni]

Summary

Wire the plugin job dispatch bridge per §4 and §17.4: plugins enqueue via the queue host ABI, the host rewrites task type to plugin:{slug}:{user_task_type} and pins queue to plugins, per-plugin concurrency semaphore + per-plugin rate limiter gate execution. Handler resolves the plugin, validates active+version, then dispatches via WASM with the manifest's job_fuel, job_memory_mb, job_timeout caps.

Design reference

• docs/12-jobs-cron.md §4 (Plugin scoping) and §17.4 (Plugin job dispatch sketch)

Acceptance criteria

• Host ABI queue.enqueue(task_type, payload, opts) -> Result<TaskID, Error> gated by the queue capability (returns EPERM otherwise)
• EnqueueOpts whitelists delay, unique_for, max_retry (capped at registry value), idempotency_key — plugins cannot set the queue
• Task type rewritten to plugin:{slug}:{user_task_type}; queue forced to plugins
• PluginTaskPayload{Slug, Version, UserType, Body, EnqueuedBy} carries plugin version
• pluginRateLimiter.Allow(slug, 1) default 60/min, configurable per-plugin by super_admin
• Per-plugin concurrency semaphore default 2 in-flight per replica
• handlePluginTask resolves plugin, returns SkipRetry if gone/inactive/version mismatch
• WASM invocation with Fuel: manifest.Limits.JobFuel, Memory: manifest.Limits.JobMemoryMB, Timeout: manifest.Limits.JobTimeout
• Default job limits: 10M fuel, 64 MB, 30s timeout; high_resource_jobs capability lifts caps (admin grants explicitly)
• plugin.activate/deactivate/uninstall.cleanup tasks wired with the §4.4 lifecycle semantics
• Rate-limit exceeded enqueues return ERATELIMIT to the plugin

Dependencies

#258, #194

Complexity

L