Support structured node location from /nodelist with legacy fallback

[kkdras]

Follow-up to #4360.
Blocked by backend change: ydb-platform/ydb#55273.

Problem

The UI currently parses the rack name from PhysicalLocation.Location in prepareNodesMap and reads the data center from PhysicalLocation.DataCenterId.

The backend PR introduces an optional top-level Location object in /viewer/json/nodelist, with structured string fields BridgePileName, DataCenter, Module, Rack, and Unit. The UI does not type or consume this object yet. Reading Location.Rack directly also avoids truncating rack names containing /.

Proposed change

• Add optional Location to TNodeInfo in src/types/api/nodesList.ts, reusing the existing structured location type where possible.
• In prepareNodesMap (src/utils/nodes.ts), prefer non-empty Location.Rack and Location.DataCenter.
• Preserve the current parsing of PhysicalLocation.Location as a fallback when the structured Rack value is unavailable, so older backends keep working. Preserve PhysicalLocation.DataCenterId as the data-center fallback.
• Do not use the legacy numeric PhysicalLocation.Rack as a rack name: it can be a hash.
• Keep the existing node-ID lookup, database scope, and parent-metadata priority in useNodeMetadata. Use the existing /nodelist request.

Acceptance criteria

• Structured Rack/DC take precedence when both structured and legacy values are present.
• Rack names containing / or =, and the string "0", are preserved.
• Responses without Location retain the current Rack/DC behavior.
• Partial, empty, and missing location data are handled without errors; unavailable values display the existing placeholder.
• Both PDisk and VDisk popups consume the resulting metadata. Space distribution continues to honor metadata passed by its parent.