feat(setup): add a setup agent step that uses OpenCode

[atornsii]

This draft adds the CLI side of the setup agent. Setup can now use an OpenCode session to add the SDK initialization code. The agent step replaces the init step in the wizard, and a new ldcli setup agent command runs only that step.

The design is in the scope doc for the ldcli setup agent. This PR covers the CLI work items that do not need a hosted service.

What changed

• ldcli setup --agent=auto|on|off. With auto (the default), setup uses the agent if OpenCode 1.19.0 or later is installed, and the templates if not. With on, setup stops with an error if the agent cannot run. With off, setup always uses the templates.
• ldcli setup agent --path . --sdk-id node-server --flag-key my-new-flag runs only the agent step. --sdk-key, --client-side-id, and --mobile-key only fill in the closing export command. The agent never receives them.
• New package internal/setup/agent. It starts opencode serve in the project directory, creates a session, sends the task, reads the event stream, answers permission requests, and stops OpenCode when the run ends.
• The wizard has a new stepAgent step. It shows finished tool calls and a y or n prompt for each permission request. After the run, it lists the changed files and the export command for the credential, and then it continues to the existing verify step.

Security

• OpenCode listens on 127.0.0.1 only, with a random password for each run (OPENCODE_SERVER_PASSWORD).
• The CLI removes every LD_ variable from the OpenCode environment, so OpenCode cannot read the access token.
• The permission rules in OPENCODE_CONFIG_CONTENT allow reads and edits in the project. They require approval for every shell command, and they deny access to other directories, web access, and sub-agents.
• The prompt tells the agent to read the credential from LAUNCHDARKLY_SDK_KEY, LAUNCHDARKLY_CLIENT_SIDE_ID, or LAUNCHDARKLY_MOBILE_KEY. No key goes into a prompt.
• If the agent fails after it edited a file, setup stops and does not apply a template on top of the partial edit.
• If the user quits while OpenCode starts, a tracker closes the run when setup exits.

Not in this PR

• AgentControl evaluation and telemetry. ConfigSource is the seam for them. DefaultConfigSource supplies built-in instructions and no model, so OpenCode uses the model that the user configured. The Go AI SDK needs an OpenCode handler first.
• The SDK relay and managed inference in gonfalon, and the CLI loopback proxy that uses them.
• --capture-content, the outcome metric, the diff with revert, and the privacy notice.
• The Go 1.26 upgrade, which the Go AI SDK needs.

Testing

• Unit tests cover the event decoder, the stream reader, the prompt, the environment filter, the permission configuration, and the version check.
• A fake OpenCode HTTP server tests the run lifecycle: the task, the events, the permission replies, and a stream that ends early.
• Wizard tests with a fake runner cover the agent step, the permission keys, the fallback in auto mode, the error in on mode, and the close on quit.
• go test -race ./cmd/setup/ ./internal/setup/... passes. go test ./... passes.
• I did not run the agent against a real OpenCode install, because OpenCode is not installed on my machine. The API shapes come from the OpenCode v1.19.3 SDK types. The process startup in server.go has no automated test.

🤖 Generated with Claude Code