fix(skooner-token): empty whitelist input clears the annotation

[arielr-lt]

Why

The Skooner token workflow takes an optional whitelist_source_range input that stamps an nginx whitelist-source-range annotation on the skooner-ingress. Previously the step was guarded by if: inputs.whitelist_source_range != '', so an empty input was a no-op — whatever a previous run had set remained in place.

This produced silent drift. A real example surfaced on prod today: a past run had set whitelist-source-range: 153.67.181.222. On the prod cluster, the ingress-nginx controller svc was externalTrafficPolicy: Cluster, so nginx never saw the real client IP (it saw a kube node IP after SNAT). Every request — from any IP, including the one in the allowlist — was rejected with 403 by nginx's access forbidden by rule. Skooner was effectively unreachable, with no obvious cause, and the workflow's "unchanged" Slack note hid the fact that the stale allowlist was still in force.

What changes

• Drop the if: guard on the whitelist step so it always runs.
• Empty input → kubectl annotate ... whitelist-source-range- (remove the annotation).
• Non-empty input → existing --overwrite set, unchanged.
• Slack notification now reports state=configured or state=cleared.

Out of scope (already done live)

• Switched prod ingress-nginx-controller svc to externalTrafficPolicy: Local so nginx sees real client IPs (sandbox already had this). The whitelist feature will now actually work on prod going forward.
• Cleared the stale 153.67.181.222 annotation on prod so the dashboard is reachable in the meantime.

Test plan

• Dispatch on test with whitelist_source_range blank → Slack shows Whitelist: cleared, annotation absent on the ingress.
• Dispatch on test with whitelist_source_range=1.2.3.4/32 → Slack shows Whitelist: configured, annotation present.
• Re-dispatch on test with blank input → annotation removed again (proves drift is reset on every run).
• Dispatch on prod with your own IP/32 → page loads only from that IP, 403 elsewhere.