fix(ai-projects): cap Foundry ARM deployment names

[hund030]

Summary

Fixes the deployment-name length failure reported in #9210. Long azd environment names currently produce Foundry ARM deployment names beyond ARM's 64-character limit, blocking both provision and preview.

Changes

• Foundry provisioning: truncate only long environment-name segments and retain deterministic environment and project-path hashes for uniqueness.
• Deployment-name tests: cover the reported Windows project path, collision resistance after truncation, and unchanged names that already fit.

Changing an existing environment's Azure location remains subject to ARM's deployment-location rules; users should create a new azd environment or run azd down before reprovisioning in another region.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
21 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Caps Foundry ARM deployment names at 64 characters while preserving stable hashes and backward-compatible short names.

Changes:

• Truncates long environment-name segments and appends environment/project hashes.
• Adds coverage for length limits, stability, and collision resistance.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
foundry_provisioning_provider.go	Implements capped deployment names.
foundry_provisioning_provider_test.go	Tests short and long naming behavior.

[jongio]

One inline question on the brownfield deployment-name path. Non-blocking: the 64-char cap and the greenfield env-name-hash disambiguation are correct as written.

[jongio]

Greenfield deploymentName() now appends an env-name hash so two long env names in the same project that truncate to the same readable prefix stay distinct. This brownfield path drops that hash: it keeps name[:keep] (the readable prefix) plus the path-hash tail and -brownfield, so two long env names that share their first ~32 characters in the same project (say foo-...-dev and foo-...-test) still collide here and would write the same RG-scoped deployment record. It's pre-existing, not introduced by this PR, but since the new env-name hash exists precisely for this disambiguation, is extending it to the brownfield name in scope, or intentionally deferred?

[jongio]

Greenfield 64-char cap and the env-name-hash disambiguation for truncated names are correct, and the added tests cover the length limit and the same-prefix collision case. My earlier note on the brownfield path dropping the env-name hash is a pre-existing edge case, not introduced here, so it's non-blocking.

[jongio]

The fix caps ARM deployment names at 64 chars and adds an env-name hash so long env names that truncate to the same readable prefix stay distinct. Slice bounds are safe in both paths since truncation only runs once the name already exceeds 64 chars, and the new tests cover the long-env-name case. The brownfield edge case I flagged inline is pre-existing and fine to defer.

[jongio]

The fix keeps names that already fit unchanged, so existing environments still update the same deployment record on re-runs. Long env names now truncate to a deterministic 64-char name, and the env-name hash keeps two long names in the same project distinct. Tests cover the reported Windows project path and collision resistance.