[Bug] Reserve space for service suffix so generated resource names stay within 63-char limit

[addielaruee]

Pull Request Description

Problem

The Console Kubernetes provider's generateResourceName allowed the base resource name to occupy the full 63-character DNS label limit. Callers then append a fixed suffix to derive related resources — most importantly the Service, named resourceName + "-svc". When the base already filled 63 characters, the Service name reached 67 and the API server rejected it:

create service "aibrix-…-svc": Service "…-svc" is invalid: metadata.name:
Invalid value: "…-svc": must be no more than 63 characters

Because the Deployment is created first, the request failed with HTTP 500 after the Deployment already existed (the rollback removed the Deployment, but the otherwise-valid user-facing request still failed).

Fix

generateResourceName now reserves room for the longest suffix appended to the base name (the Service's -svc) in addition to the prefix, the joining dash, and the unique suffix — so every derived name stays within the limit. To make the invariant explicit and drift-proof (the root cause was the generator not knowing about the suffix callers append), the magic values are extracted into named constants and the "-svc" literal is replaced with serviceNameSuffix at every use site:

• maxResourceNameLength (63), resourceNamePrefix (aibrix-), resourceNameUniqueSuffixLength (8), serviceNameSuffix (-svc)
• The base name is truncated to maxResourceNameLength - len(prefix) - len("-") - suffixLen - len(serviceNameSuffix) before the unique suffix is appended, and the random suffix is always preserved.

Deployment and HPA names use the base name directly (no appended suffix), so they were already within the limit and remain so.

Testing

go test ./apps/console/api/deployment/provider/..., go vet, gofmt, and go build ./apps/console/... all pass. Added two tests (verified they fail without the fix):

• TestGenerateResourceNameDerivedNamesStayWithinKubernetesLimit — table test over names below, at, and above the boundary (incl. the 100-char case from the report). Asserts the final resourceName + "-svc" — not just the base — is a valid label via validation.IsDNS1035Label, and that the unique suffix survives truncation.
• TestCreateWithLongNameProducesValidKubernetesResourceNames — end-to-end Create with a 100-character name that asserts the actual created Deployment, Service, and HPA object names are valid DNS labels. (The fake client does not enforce API-server name validation, so names are validated explicitly, as the issue suggests.)

Acceptance criteria

• Generated Deployment, Service, and HPA names satisfy their Kubernetes naming limits.
• Long deployment names no longer cause Service creation to fail with HTTP 500.
• The random suffix remains present after truncation.
• Tests cover names below, at, and above the boundary.
• Tests assert the validity of the final resourceName + "-svc", not only the base name.

Related Issues

Resolves: #2493

[gemini-code-assist]

Code Review

This pull request refactors Kubernetes resource name generation to ensure that derived resource names, such as Services with a -svc suffix, do not exceed the 63-character Kubernetes DNS label limit. It introduces constants for name lengths, prefixes, and suffixes, and dynamically calculates the maximum base name length to reserve space for these suffixes. Additionally, unit tests are added to verify that long deployment names produce valid, within-limit resource names. I have no feedback to provide as there are no review comments.

[Jeffwan]

overall looks good to me. thanks