fix(ui): create flow - name trimming issue

[siddhant-galileo]

Summary

• What changed and why.
  Fix - https://galileoteamworkspace.slack.com/archives/C09TKBCRABG/p1773172188238399?thread_ts=1773165596.478009&cid=C09TKBCRABG
  Also login modal icon fixed

• Fixed logo color on login modal.

Scope

• User-facing/API changes:
• Internal changes:
• Out of scope:

Risk and Rollout

• Risk level: low / medium / high
• Rollback plan:

Testing

• Added or updated automated tests
• Ran make check (or explained why not)
• Manually verified behavior

Checklist

• Linked issue/spec (if applicable)
• Updated docs/examples for user-facing changes
• Included any required follow-up tasks

[lan17]

Added two inline review comments.

[lan17]

I think the main unresolved issue here is the contract boundary.

This repo already has a clear pattern for agent names: normalization is defined once and applied consistently across shared models, server endpoints, and SDK entry points. Control names still do not have that. In this PR, the only canonicalization being added is inside one UI flow, while the server create/patch endpoints and both SDKs still treat name as caller-provided input.

That matters because non-UI clients are real clients here. A browser user now gets trimming/canonicalization in the modal, but Python and TypeScript SDK callers still need to know to pre-trim or they will just hit API validation. I think we should make that choice explicit: either control-name canonicalization belongs at the server/shared boundary, or this remains validation-only and every client is responsible for sending canonical names. I would avoid implicitly defining canonical control names in one modal.

Separately, the legacy-name policy should be explicit and covered by a regression test. The code reads like “existing invalid names remain editable unless the user actually renames them”, which seems reasonable, but it should be stated and tested directly.

The login logo swap also looks unrelated to the trimming fix. If it’s intentional, I’d explain it in the PR; otherwise I’d split it out.

[siddhant-galileo]

I think the main unresolved issue here is the contract boundary.

This repo already has a clear pattern for agent names: normalization is defined once and applied consistently across shared models, server endpoints, and SDK entry points. Control names still do not have that. In this PR, the only canonicalization being added is inside one UI flow, while the server create/patch endpoints and both SDKs still treat name as caller-provided input.

That matters because non-UI clients are real clients here. A browser user now gets trimming/canonicalization in the modal, but Python and TypeScript SDK callers still need to know to pre-trim or they will just hit API validation. I think we should make that choice explicit: either control-name canonicalization belongs at the server/shared boundary, or this remains validation-only and every client is responsible for sending canonical names. I would avoid implicitly defining canonical control names in one modal.

Separately, the legacy-name policy should be explicit and covered by a regression test. The code reads like “existing invalid names remain editable unless the user actually renames them”, which seems reasonable, but it should be stated and tested directly.

Fixed this - moved logic to server now. UI only uses trim to check if name has updated or not

The login logo swap also looks unrelated to the trimming fix. If it’s intentional, I’d explain it in the PR; otherwise I’d split it out.

Added a line in PR description

[lan17]

Looks good to me.