Import a declarative environment list without putting credentials in configuration

[colonelpanic8]

I manage several T3 Code environments through Nix and would like the same declaration to produce a file I can import into the mobile client. That would avoid entering every server address on each new device, without distributing credentials in a configuration file.

This follows #19594's shared-versus-machine-local settings discussion, but adds another boundary: configuration versus credentials. A value can be machine-local and still need secret storage.

Proposed workflow:

1. Nix (or another configuration tool) generates a versioned JSON artifact containing environment IDs, labels, and connection URLs only.
2. The client previews the environments and imports them. Reimporting is idempotent and preserves existing connections and credentials; a changed URL must not silently receive an existing credential.
3. Enrollment happens separately. In a deployment that supports fleet enrollment, pairing with one member can establish individual sessions with the other members. Importing the file alone grants no access.
4. Credentials stay in the client's credential store. Server-side provisioning uses separately supplied runtime secrets, rather than embedding secret values in the generated artifact or Nix store.

Offline members should remain visible as pending, with a way to retry. Import should reject credential fields and credential-bearing URLs. The declaration should also remain separate from mutable connection status and UI state.

I have a local fork with fleet enrollment and am implementing an import flow there to test this. The portable artifact should not depend on Nix or Tailscale; those are just my deployment tools. This is separate from migrating an entire environment/database (#18297).

Would you want this direction upstream? In particular:

• Should the portable format be a small connection manifest, or part of a broader client configuration format?
• Should an imported list remain declarative desired state, or be a one-time addition to the client's saved environments?
• Is enrolling a group of environments a useful follow-up, or would you prefer the initial import feature to require each environment's existing pairing flow?

I'll keep the implementation on my fork while the direction is discussed, per CONTRIBUTING.md.

[colonelpanic8]

A concrete extension I want to explore in my fork is declarative environment groups with session-only visibility overrides.

I manage family members’ machines as well as my own development machines. I want those family environments saved and paired, but normally absent from my everyday workspace. I should be able to deliberately show the Family group when doing maintenance, then return to the declared defaults next session.

The declaration would define stable group IDs, labels, member environment IDs, and a default visibility for each group. The client would offer group toggles for the current session; toggling would never rewrite the declaration or forget pairings. Ungrouped environments would keep the existing behavior. Groups should apply consistently across environment/project pickers, thread lists, and search, rather than only collapsing sidebar rows.

This complements #6955: that discussion focuses on filtering connected environments, whereas this use case needs declarative defaults and an explicit lifetime for overrides. For this use case, hiding is strictly a visibility filter: the machines stay connected, saved pairing and per-environment connection settings stay unchanged, and remote work continues. Visibility overrides last until the client reloads or restarts; navigation and backgrounding do not reset them.

I’ll develop this on my fork while the upstream direction is discussed. Would group membership and default visibility fit the portable manifest proposed here, with activation kept as client-local session state?