Normalize agent harness terminology

[harshitsinghbhandari]

This was generated by AI during triage.

Summary

The rewrite currently uses both Agent/agent and Harness/harness terminology for what appears to be the same user-facing concept: the selected agent CLI adapter, e.g. claude-code, codex, aider, or opencode.

This should be normalized to AgentHarness in Go identifiers and to a clear wire/API name such as agentHarness or defaultAgentHarness where the value is project/default-scoped.

Context

During #91 review, the project DTO field was called Agent:

Agent string `json:"agent,omitempty"`

But the value is conceptually the agent harness/default harness, not a separate project “agent” object. Sessions already use harness terminology in several places:

• domain.AgentHarness
• SpawnSessionRequest.Harness
• domain.SessionRecord.Harness
• daemon AO_AGENT is effectively the default harness when a session does not specify one

The terminology makes it hard to tell whether agent means:

1. the adapter implementation (ports.Agent), or
2. the selected adapter id / CLI harness (claude-code, codex, etc.).

Proposed direction

Audit and rename the confusing references so the selected adapter id is consistently called AgentHarness.

Potential target naming:

• Go domain type remains/standardizes as domain.AgentHarness.
• Session fields currently named Harness become AgentHarness where appropriate.
• Project/default fields should become DefaultAgentHarness if they represent the fallback used for new sessions.
• API JSON fields should be deliberately chosen (agentHarness, defaultAgentHarness) with a compatibility/migration plan if existing clients consume harness or agent.

Scope notes

This was intentionally not done in #91 because that PR only adds ao project ls/get/rm CLI commands and should not bundle a domain/API terminology migration.

Acceptance criteria

• The codebase has a clear distinction between:
  • agent adapter implementations (ports.Agent, adapter packages), and
  • selected agent harness ids (domain.AgentHarness).
• Project/session DTO fields use AgentHarness or DefaultAgentHarness naming where that is the actual concept.
• Existing API compatibility is considered explicitly; if wire names change, add transitional behavior or document the breaking change.
• Tests are updated to cover the renamed fields and any backwards-compatible JSON aliases.