fix: pass workspace from YAML import to agent definition

[dajiaohuang]

Summary

When importing a project via YAML, the workspace was parsed and stored in the normalized spec but never bound to the agent. AgentDefinition.WorkspaceID was always empty, so agents started in an empty directory.

Agent-level workspace takes precedence; project-level workspace is used as fallback.

Testing

go build ./pkg/compose/ and go build ./pkg/agentcompose/ pass.

Checklist

• Documentation updated when behavior or configuration changed.
• Tests added or updated for user-visible behavior.
• No secrets, private endpoints, internal certificates, or local runtime state included.

Fixes #33

[eetoc]

Thanks for the fix. The direction makes sense to me: YAML-imported managed agents should not lose the workspace declared in the project spec, especially when the managed agent is started outside the project-run path.

One thing I am not fully sure about from this patch: projectManagedAgentDefinitionFromSpec now fills AgentDefinition.WorkspaceID with a deterministic ID, but I could not find where ApplyProject creates or upserts a matching WorkspaceConfig for that ID. Later, agent validation / CreateAgentSession resolves WorkspaceID through GetWorkspaceConfig, so if the config row does not exist the managed agent may show as unavailable with workspace config <id> not found.

Project runs already seem to materialize workspace from the project revision spec at run time, so this mainly matters for using the imported managed agent through the normal agent-definition/session path.

Could we confirm that the matching workspace config is persisted somewhere, or add that as part of this change? A regression test that applies a project with project-level + agent-level workspace and then verifies the managed agent workspace resolves successfully would make this much clearer.