fix(sync): tolerate non-numeric shard and replica names in stale replica cleanup

[melancholictheory]

Why

listStaleDatabaseReplicasQuery casts database_shard_name and database_replica_name from system.clusters with toInt32. That table lists every cluster the server knows about, not only the Replicated databases the operator numbered: the static clusters from remote_servers carry empty names, and a Replicated database created by a user with its own shard and replica names carries whatever the user chose. Neither parses as an integer, so the cast throws, CleanupDatabaseReplicas fails, SchemaInSync stays ReplicasNotCleanedUp, and reconciliation loops on that step without starting new pods. #349 reports it with Code: 32 on the empty string.

What

Use toInt32OrNull for both casts and drop the rows where either is NULL. Names the operator did not choose can no longer break the query, and the rest of the cleanup logic sees exactly the rows it saw before, since a row with a non-numeric name was never something it could act on.

The database_replica_name != '' guard is folded into the NULL filter: an empty name gives NULL too.

Testing

The commander integration suite gets a spec that creates a Replicated database with shard-a / replica-b names on one replica and runs CleanupDatabaseReplicas against the cluster. Without the fix that fails on the cast; with the fix it succeeds and leaves the database alone.

On the exact Code: 32 from the report: I could not make a static default cluster trigger it on 25.8.32.4 or 26.7.5.10, single node or three nodes, remote execution forced, short-circuit evaluation disabled or not; the database_replica_name != '' filter was applied before the cast every time. The report does not say which version hit it, so the test uses the non-numeric case, which is the same defect and reproduces on every version. The fix covers both because the cast is now total.

Related Issues

Fixes #349