Normalize FloatParameter values to float to stabilize task_id (#3243)

[jaideeppyne]

Description

Fixes #3243 ("int values to FloatParameter crashes worker").

FloatParameter defines only parse and inherits the base no-op normalize (which returns the value unchanged) and the base serialize (str(x)). Nothing coerces a stored value to float, so an int input survives as an int:

p = FloatParameter()
p.serialize(5)    # -> "5"
p.serialize(5.0)  # -> "5.0"

Two logically-equal values (5 == 5.0) therefore produce different task_ids. Across the scheduler↔worker boundary the assistant worker keys its scheduled tasks by the server's id but looks them up by the locally recomputed id, so the divergence surfaces as a KeyError that crashes the assistant (exactly the traceback in the issue).

Verified on master:

Foo(args=5).task_id    -> Foo_5_cecf3ca63d
Foo(args=5.0).task_id  -> Foo_5_0_a9203c326b     # diverge

(Within one process the instance cache masks it because 5 == 5.0; clearing Register.clear_instance_cache() between instantiations — as the reporter does — exposes it.)

Fix

Add FloatParameter.normalize to coerce the value to float (with a None guard so OptionalFloatParameter still works). normalize is applied to every parameter value, so T(5) and T(5.0) canonicalize to 5.0 → the same task_id. With the fix both yield Foo_5_0_a9203c326b. This mirrors the reporter's own serialize(float(x)) workaround, applied at the right layer.

Tests

test/parameter_test.py:

• test_float_normalizes_int_to_float — FloatParameter().normalize(5) is 5.0 (a float), and equal int/float values serialize identically.
• test_float_task_id_stable_for_int_and_float — a task with args=5 vs args=5.0 (instance cache cleared between) yields the same task_id.

Both fail on master and pass with the fix.