Replace Redis Streams queue and controller

[rakyll]

Transition the AX architecture from event queues (Redis Streams and the ax-controller worker pool) to direct, synchronous reconciliation in ax-server guarded by fine-grained distributed locks.

Key changes:

• Implement per-resource locking (lock:task, lock:workspace, lock:model) using Redis distributed locks (SET NX PX with token validation) and an in-memory locker for testing.
• Move Substrate reconciliation directly into ax-server for Task, Workspace, and Model lifecycle methods (Create, Resume, Suspend, Delete).
• Decommission ax-controller, deploy/ax-controller.yaml, and Redis Stream event publishing/consuming interfaces.
• Simplify ax delete and ax watch in the CLI to eliminate two-phase polling loops now that operations complete synchronously.
• Update demo.sh, build configurations (Makefile, .ko.yaml), and documentation to reflect the single-binary control plane architecture.

[adirothbuilds]

One recovery-contract question related to #418: removing the worker and queue would supersede the ACK-specific fix I have prepared.
In the current draft, if Substrate reconciliation succeeds but UpdateTaskStatus fails, the RPC returns an error while the persisted status may remain stale. For CreateTask, the record has already been saved, so retrying the same create is rejected as already existing.
What is the intended recovery path for this partial-success case? Is recovery expected to be client-driven, or should the server retry persisting the computed status without repeating the Substrate operations?
Raising this while the design is still in draft, since it affects how #418 should be handled.