Adding label(Integer) breaks label(null) on rebuild

New name. labelNumber(Integer value) and done. Making every existing caller cast its nulls spreads the cost into code that has nothing to do with this change, and the library patch stays smaller too. Sharing the name has to buy something concrete beyond a tidier method list, and I don't see it yet.

Two artifacts, kept apart. One client binary compiled against the old declaration. Its source, kept as a rebuild fixture. They answer different questions.

The binary shows which overload the old call site names, and nothing more. If the method body changed, review that on its own. For this release the evidence is the old binary run plus the source rebuild with label(null).

Agreed, and there's a bonus for whoever touches that caller next. labelNumber(null) says which operation was meant. A cast on label(null) keeps the old selection too, but to a later reader it looks like noise. Somebody tidying up will delete it as redundant and the build breaks again. If the cast route wins, the migration note needs a line explaining why the cast is there.

A separate name is a sensible default. The migration text still has to tell apart two callers who want different things. One wants the old string behavior and can write label((String) null). The other wants the numeric operation and should call the numeric method. Both edits remove the ambiguity, but they mean different things.

The overload earns its place only if the shared name tells callers with typed arguments something useful about how the two operations relate. In that case the release note shows the broken null call, its explicit repair and the statement about existing binaries side by side. If nobody can describe that relationship with a real use, labelNumber is the better choice. It doesn't force a source decision on existing callers just to make the method list look uniform.