feat(connectors): inject every connected account slot, not just the winning one

[koreankop]

Summary

A principal can connect the same provider more than once — the default, personal, and company slots each hold their own token, and connectorTokenStatus already reports them separately. A turn, however, only ever saw one: the first hit of personal → default → company landed in VAULT_TOKEN_<HOST> and the other slots were invisible to the agent.

So someone with a personal and a company Google account connected can reach exactly one of the two mailboxes, and has no way to name the other. Nothing surfaces the ambiguity either — the connector page shows the provider as simply "connected".

This change keeps the unsuffixed variable exactly as it was, same precedence and same value, and additionally exports VAULT_TOKEN_<HOST>__DEFAULT / __PERSONAL / __COMPANY for each slot that is actually connected, but only when more than one is. A single-slot connector's environment is byte-identical to before, so existing skills keep working as written, and a skill that wants a specific account can now address it.

The slot list comes from the existing CONNECTOR_STATUS_ACCOUNT_TYPES, so the injection and the status view stay in step if a slot is ever added.

Test plan

node --experimental-test-module-mocks --test test/connector-invariants.test.ts — 10/10 pass, tsc --noEmit and eslint clean. Two new cases against the existing exec-env harness:

• two slots connected (default + company): the unsuffixed variable still carries the default slot's token, and the company slot arrives as its own variable (this test fails on main);
• one slot connected: only the unsuffixed variable is exported, no __ variables at all.

Verified end to end on a live instance with two Google accounts in one workspace: before, the agent could only read one mailbox; after, it reads and reports both, and the existing single-account skills were unaffected.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[time-attack]

Thanks for this, @koreankop — and sorry for the slow response.

We're closing this PR. Per CONTRIBUTING.md, since coding agents write most of the underlying code now, we'd rather receive feature ideas as a short human-written note in adrs/ — informal is great, just the idea in your own words — and bugs as a plain issue. If we're aligned we're happy to burn our own tokens on the implementation, and we'll credit you as co-author.

We don't want your idea to get lost, so we've captured it in #754 to triage on our side. Please feel free to open an adrs/ note if you feel strongly about the approach. Appreciate you engaging with the repo!