What this change does

• Populate denormalized name columns on write: Centralizes NodeEntity validation in NodeInfoDao so that on every upsert we:
  • Copy user.publicKey into NodeEntity.publicKey (for lazy migration and consistency).
  • Populate longName and shortName from the MeshProtos.User payload when the user is not a placeholder (hwModel != UNSET).
• Backfill existing rows for search: Adds a backfillDenormalizedNames() DAO method (exposed via NodeInfoWriteDataSource and SwitchingNodeInfoWriteDataSource) that:
  • Scans all nodes and fills in missing longName/shortName from the associated user protobuf.
  • Skips placeholder/default users to avoid polluting search with dummy entries.
• Run backfill once on startup: NodeRepository now kicks off the backfill in processLifecycle.coroutineScope.launchWhenCreated on the IO dispatcher so existing databases get corrected without blocking the UI.
• Wire search & filters through the repository:
  • NodeRepository.getNodes(...) exposes a flow backed by the Room query in NodeInfoDao.getNodes, which now searches against the denormalized long_name / short_name columns and node ID (both hex and decimal).
  • NodeListViewModel combines user preferences and filter state into a single NodeFilterState, then calls nodeRepository.getNodes with sort, filterText, and flags (includeUnknown, onlyOnline, onlyDirect, infrastructure/ignored filters).
  • An additional unfilteredNodeList flow is provided for call sites that need the raw list without UI filters.

Why this fixes the bug

• Previously, node search could fail or behave inconsistently because the denormalized name columns were not reliably populated, especially for existing databases or nodes created before the columns were introduced.
• By ensuring denormalized columns are populated on every write and backfilled once on startup, the SQL query powering search now has consistent data to match against, so:
  • Searching by node long/short name works for both new and existing nodes.
  • Searching by node ID (hex or decimal) is supported via the updated query conditions.
• The existing public-key validation and impersonation safeguards remain intact, while search and sorting now operate on well-defined, denormalized fields.