fix(lb): reject a balancer name Hetzner does not accept

[lexfrei]

A balancer name from the robotlb/balancer annotation now gets checked before robotlb looks a balancer up by that name or creates one. Before this, any value went to the API as is. Hetzner takes 1 to 128 characters matching ^\S(.*\S)?$, per the name schema of POST /load_balancers in its OpenAPI spec. So a name with whitespace at the start or end, a line break, or more than 128 characters failed with 422 on every retry. An empty value was used as the name too, first in the lookup and then in the create.

A bad name fails the reconcile with a new InvalidBalancerName error, and the usual failure path shows it as a warning event on the Service. The message states the rule before the name, since event notes get cut at 1024 bytes. The check sits right after the lookup by the service UID label, not in LoadBalancer::try_from_svc. A service whose balancer already carries that label never uses the name, so it keeps being managed whatever the annotation says, same as before. A release still reads no annotations.

The check follows the regex dialect of the schema, ECMA-262. That decides the rare cases: . stops at U+2028, and U+FEFF counts as whitespace. I can't tell which regex engine Hetzner runs on the server, so an odd character may still be judged differently there.

The second commit drops the unused LB_NODE_IP_LABEL_NAME constant. Nothing in the code, README or Helm chart reads robotlb/node-ip.

Uniqueness is not part of the check. A name already taken in the project is found by the lookup by name, and the service either uses that balancer or gets a warning event.

The README doesn't describe the name rule. It didn't before either, so I left it as is.

Stacked on #64.

Closes #61

[s3rius]

I'm not sure if we want this change. Since hetzner will reject the request anyway. Also, as part of reconcilation the request will be retried.

And aside from that they can update their name policies, which we will need to support. Generally I don't think it's necessary.

[s3rius]

There is a convenient method for this:

Suggested change

	let one_line = !name.contains(['\n', '\r', '\u{2028}', '\u{2029}']);
	let one_line = name.lines().count() == 1;

Also, few side notes:

• \r can appear without \n, which is not a new line.
• \u{2028} and \u{2029} should only be interpreted by text editors, most probably it's going to be ignored. But it really depends on the implementation. https://unicode.org/versions/Unicode5.2.0/ch05.pdf
• We can simplify checks by only allowing ascii encodable strings.

[lexfrei]

@s3rius Closing this. Hetzner already rejects a bad name with an error that says what is wrong, and since #55 the retries back off. A check on our side would mostly be a copy of their rule that can go stale. Same story as the annotation in #47: while building the stack I didn't notice this part could go.

I'll send the unused constant cleanup from this branch as a separate small PR and move #68 off this branch.