fix(kuberay): preserve useful characters when truncating K8s label values

[peterroelants]

Problem

normalize_k8s_label_values strips leading/trailing non-alphanumeric chars before truncating to 63. For long inputs (e.g. a branch name stuck into dagster/git-branch), the 63rd character can be _, -, or ., which fails the K8s label-value regex (([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?. This breaks RayClusterResource creation with HTTP 422, cascading into a 404 at cleanup.

Fix

Split the leading/trailing strip into two steps around the truncation:

1. Strip leading non-alphanumerics — so a leading _ / . run doesn't eat the 63-char budget on characters we'd immediately strip anyway.
2. Truncate to 63.
3. Strip trailing non-alphanumerics — handles whatever character truncation lands on.

Then validate the result against the K8s label-value regex and raise if it doesn't match, so any future regression in this function surfaces at normalize time instead of at the K8s API.

Tests

• The existing snapshot test now also checks every output against the K8s label-value regex.
• test_normalize_k8s_label_values_truncated_tail_is_alphanumeric is extended with long leading _ / . runs and the §-style leading-garbage case from the review.
• New test_normalize_k8s_label_values_preserves_useful_tail_after_leading_garbage pins the "useful tail survives" property.
• New test_normalize_k8s_label_values_rejects_unexpectedly_invalid_output patches the trailing-strip to a no-op and asserts the K8s-regex validation raises.

[danielgafni]

@peterroelants could you please update the PR description to something more concise (or I could do it if you're ok with it)

I'm a bit hesitant about this fix since the initial truncation may drop a lot of useful characters. Imagine this input string: §§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§<x63>-finally-something-useful. It would not work with the new order of doing things.

If the problem is with just the very last character then perhaps we could fix just it? It seems like how we handle it with _LEADING_TRAILING_NON_ALNUM_PATTERN is the problem in the first place.

We should also update our test suite with the correct k8s regexp to prevent this kind of problems in the future. Ideally if we verify regex matching at label creation time as well.

[peterroelants]

@danielgafni I should've addressed your comments

[danielgafni]

Thanks!

[peterroelants]

Thanks!

Great, you're welcome.

Btw, I don't think I have merge permissions on this, so I'll leave merging this in up to you.