Fix table rename on a DataNode that missed the pre-release

[alpass163]

Problem

A rename is pre-released to every DataNode (PRE_UPDATE_TABLE) before the ConfigNode
commits it. A DataNode that registers during that phase is not in the broadcast target
set — it is frozen when the propagator is built — but it does receive the later commit
release. Such a DataNode ends up in a wrong state:

• its activation snapshot still holds the table under the old name, and
• commitUpdateTable finds no pre-released entry for the new name, so it only logs
  "skip commit update ... because it has been handled" and returns.

The old name therefore stays in the cache as a usable table, and the new name is
reported as TABLE_NOT_EXISTS on that DataNode. It only heals on lease recovery or
restart.

Fix

• DataNode (DataNodeTableCache): on a commit that finds no pre-released entry and
  carries an oldName, repair the cache — drop the old name from databaseTableMap and
  leave a NonCommittableTsTable placeholder for the new name. The placeholder routes
  the next lookup of the new name into the existing lazy-fetch path, which pulls the
  committed definition from the ConfigNode. A repeated commit is idempotent: while the
  placeholder exists the commit returns at the NonCommittableTsTable check, and after
  a fetch has consumed it the repair skips re-marking a table that is already cached.
• ConfigNode (AbstractAlterOrDropTableProcedure): the commit release of a rename
  is now broadcast through ClusterCachePropagator, the same delivery guarantee the
  pre-release already has.