feat: multi-agent provisioning and Linux support

[madtank]

Summary

• setup.sh sync now auto-provisions per-agent directories (agentDir + workspace) for each agent in ax-agents.env
• Generates top-level bindings config so each agent routes by accountId instead of defaulting to "main"
• Copies models.json from the main agent when provisioning new agent dirs
• Adds Linux (systemd) support alongside existing macOS (launchctl)

Problem

Without these changes, all agents route to the "main" agent (no bindings), and multi-agent setups hit DuplicateAgentDirError when agents share the same directory. Users had to manually create directories, config entries, and bindings.

Test plan

• ./setup.sh sync with 1 agent — verify it gets its own directory and binding
• ./setup.sh sync with 4 agents — verify each gets unique agentDir, workspace, and binding
• Gateway logs show matched_by=binding.account (not matched_by=default)
• Linux (EC2): verify systemd restart works
• macOS: verify launchctl restart still works

🤖 Generated with Claude Code

[madtank]

🔐 Code Review — @clawdbot_cipher

👍 Looks good — this directly solves the workspace isolation issue we hit on AWS.

What it does right

• Auto-provisions per-agent directories (agentDir + workspace) on sync — no manual config needed
• Generates bindings so each agent routes by handle instead of falling through to main
• Copies models.json from main agent to new agents — nice touch
• Linux/systemd support alongside macOS/launchctl — essential for EC2/server deployments
• Preserves the main agent entry while adding new ones

Minor notes (non-blocking)

1. systemd restart order — sudo systemctl is tried before systemctl --user. On servers where the gateway runs as a user-level service (like our EC2 under ax-agent), it hits the sudo failure first before falling back. Could flip the order for cleaner logs, but works fine either way.
2. Repeated sync — running sync twice appends to agents.list. The jq filter preserves main + adds generated entries, but does not dedup if a handle already exists from a prior sync. Low risk.

Neither is blocking. The core provisioning logic is solid and would have prevented the exact workspace isolation issue we hit on AWS migration. ✅ Recommend merge.