feat(config): multi-developer support via automation.json + companion /whoami

[marcoaperez]

Lets multiple developers work against the same FMS-hosted solution, each from their own machine with their own companion server, without hardcoding If Get(AccountName) = "..." branches into the FM script.

This follows up on #30, which was a design-only writeup closed without comment — this time with working, testable code instead of just a proposal doc.

What this adds

• automation.json.example documents an optional users section, keyed by FileMaker account name (Get(AccountName)), holding each developer's repo path and companion host/port.
• companion_server.py gets GET /whoami?account=<name>, which resolves that block from automation.json. Returns 400 with a clear message when the account isn't configured (or automation.json has no users section at all) — callers fall back to the existing folder-picker/cached-global behavior.
• filemaker/README.md documents the setup under a new "Multi-developer setup" section.

Scope

This PR covers the config + companion side only, which is fully testable outside of a live FileMaker instance (see test plan below). Wiring this into Get agentic-fm path / Explode XML on the FM script side — so it calls /whoami instead of relying solely on the folder-picker dialog — is a natural follow-up once this direction lands. Happy to iterate on that once this part is reviewed. The existing folder-picker flow is untouched and keeps working exactly as before; users is entirely optional and backward-compatible.

Test plan

$ curl "http://127.0.0.1:8765/whoami?account=testuser"
{"account": "testuser", "repo_path": "/tmp/x", "companion_host": "10.0.0.5", "companion_port": 8765}

$ curl -w "\nHTTP %{http_code}\n" "http://127.0.0.1:8765/whoami?account=nobody"
{"error": "Account 'nobody' not configured"}
HTTP 400

$ curl -w "\nHTTP %{http_code}\n" "http://127.0.0.1:8765/whoami"
{"error": "Missing required 'account' query parameter"}
HTTP 400

• Known account returns its configured block
• Unknown account returns 400 with a clear message
• Missing account query param returns 400
• No users section in automation.json at all → same 400 path, no crash

[agentic-fm]

Thank you, @marcoaperez — this is a good direction, and the implementation is clean (optional users block, 400 on an unknown account, folder-picker flow untouched, backward-compatible).

I want to hold it briefly rather than merge piecemeal. This PR introduces a per-developer companion_host / companion_port schema in automation.json, and we have a closely related need surfacing right now: the companion host/port is currently spread across a hardcoded default, an env var, a --port flag, automation.json's companion_url, and (with this PR) the users block — no single source of truth, which is why things like the session-start health check break when someone runs a non-default port.

Rather than land two overlapping port-config mechanisms, we're going to design one canonical companion config that both your /whoami path and the base companion/startup checks consume, with your users[account] block as the per-developer override layer on top of it. Your work here is a core input to that — nothing is wasted; it just gets folded into a coherent whole so we don't ship a half-wired endpoint (the /whoami consumer, the "Get agentic-fm path" FM script, is still deferred here anyway).

Marking triage/later and keeping it open. I'll follow up with the config shape so you (or we) can rebase this onto it. Appreciate you pushing this forward. 🙏

[agentic-fm]

The base companion config this PR's override layer was deferred to design against has landed in acc480e. It ships the users block schema in agent/config/companion.json.example (per-account repo_path, companion_host, companion_port, keyed by Get(AccountName)), so the /whoami override can now be built on a settled base without a schema redesign.

How it slots in (see agent/docs/COMPANION_SERVER.md):

• users[<account>] sits in client-reach resolution, above the base advertise_host + port — it changes what a client dials, never how the server binds. Keep it out of the server-bind chain.
• GET /whoami?account=<name> resolves the users entry over the base companion block and returns the reach host/port + repo_path.
• Plug-in detection is per-companion, not per-Get(AccountName) — /health carries no account and the detection cache is process-global. /whoami must not attempt to route plug-in detection per account; the companion brokers the one plug-in it shares a macOS login with.

One divergence to settle: this PR's title puts users in automation.json, but acc480e ships the users schema in companion.json (the single companion-config source in COMPANION_SERVER.md). Please align /whoami to read users from companion.json — or push back here if automation.json is preferred — so we commit to one location before merge.