bug: agent-project import leaves tools unauthorized and provider mis-mapped

[AutomateIP]

Description

ipctl import agent-project leaves imported agents in a partially broken state on the
destination instance, in two related ways:

1. Tool references get demoted to unauthorizedReferenceId. Every adapter-tool
   reference on every imported agent came back as {"unauthorizedReferenceId": "...", ...}
   instead of {"referenceId": "...", ...} after import — even for tools confirmed to
   exist in the destination's tool registry (verified via GET /tools, paginated through
   all ~1000 entries). This happened consistently across 5 agents in 2 separate imported
   projects, for both adapter:* and one application:ConfigurationManager:* reference in
   isolated cases. gatewayService:* and view:* references were unaffected.
2. provider (LLM profile/model) is not correctly remapped. For one imported agent, the
   provider.profile id resolved correctly to the destination's equivalent profile
   (matched by name), but provider.model resolved to the wrong model within that
   profile (the profile's first/default model rather than the source agent's actual
   model). For four other imported agents (in a different project), provider came back
   as null entirely — no profile or model was set at all, even though a
   same-named profile existed on the destination for two of the four agents.

Both defects require a manual PATCH /agent-project-service/agents/{agentId} after import
to fix — authorizeTools for (1), provider for (2) — before the imported agent will run
correctly against the destination's registered tools and LLM configuration.

Reproduction Steps

1. On a source Platform instance, ipctl export agent-project "<name>" --profile <source>
   for a project with agents using adapter/application tools and an LLM provider
   (profile + model).
2. ipctl import agent-project "<file>.agent-project.json" --profile <destination> against
   a fresh destination instance that already has the equivalent adapters running and the
   equivalent LLM profile registered.
3. GET /agent-project-service/agents/{agentId} on the destination for each imported
   agent:
   • Tool entries that should read {"referenceId": "adapter:X:Y:method", ...} instead
     read {"unauthorizedReferenceId": "adapter:X:Y:method", ...}.
   • provider is either null, or has the correct profile id but the wrong model id
     (defaulting to another model in the same profile rather than the source's model).
4. Confirm the referenced tools actually exist on the destination:
   GET /tools?skip=0&limit=200 (paginate through total) — the "unauthorized" tools are
   present in the results, so the demotion isn't due to a missing tool.
5. Manually fix each agent with:
   • PATCH /agent-project-service/agents/{agentId} body
     {"authorizeTools": [{"referenceId": "adapter:X:Y:method"}, ...]} — re-authorizes the
     tool references, one call per agent listing every affected tool.
   • PATCH /agent-project-service/agents/{agentId} body
     {"provider": {"profile": "<correct-profile-id>", "model": "<correct-model-id>"}} —
     fixes the LLM binding.
6. After the manual PATCHes, GET the agent again — unauthorizedReferenceId is gone,
   replaced by referenceId, and provider shows the correct profile/model.

Expected Behavior

• ipctl import agent-project should authorize every tool reference against the
  destination's tool registry as part of the import, so agents don't come back in an
  unauthorizedReferenceId state for tools that genuinely exist on the destination.
• ipctl import agent-project should correctly remap provider.profile AND
  provider.model by matching names against the destination's registered LLM
  profiles/models (GET /agent-project-service/profiles), rather than leaving provider
  null or picking an unintended model within the right profile.

Environment

• OS: macOS (Darwin 25.5.0)
• Version: ipctl v0.12.0-132-gca82f65
• Go Version (if applicable): go1.26.5 darwin/arm64

Checklist

• I have checked existing issues to avoid duplicates
• I have provided a clear description of the issue
• I have included steps to reproduce (if applicable)
• I have included relevant environment details