core,schedule: use KiB as the canonical internal unit for region sizes

## Enhancement Task

### Background

#10656 switched PD's internal `approximateSize` from MiB to KiB to improve empty-region detection. During that work we discovered that size values throughout PD are plain `int64` with no unit annotation. Fields like `LeaderSize`, `RegionSize`, `approximateSizeKib` carry their unit only in naming conventions, not in the type system.

This caused real bugs: `step.go` wrote KiB values into `StoreInfluence.LeaderSize` / `RegionSize` fields that the store-scoring functions treat as MiB. No compiler error — just silently wrong scheduling decisions.

### Proposal

1. Introduce a named type `type SizeKiB int64` in `pkg/core/` (or `pkg/units/`).
2. Use `SizeKiB` for **all** internal region/store size fields: `RegionInfo.approximateSizeKib`, `StoreInfluence.RegionSize`, `StoreInfluence.LeaderSize`, `StoreInfo.regionSize`, `StoreInfo.leaderSize`, thresholds like `EmptyRegionApproximateSize`, `SmallRegionThreshold`, etc.
3. Drop the separate MiB-denominated fields (`approximateSize`, `GetApproximateSize()` returning MiB). KiB is the single source of truth internally.
4. Convert to MiB **only** at the API/JSON boundary for backward compatibility (`approximate_size` in API responses, Prometheus metrics). Plain `int64` division at the edge, no `SizeMiB` type needed.

This makes any MiB/KiB confusion a compile-time error rather than a silent scheduling bug.

### Related

- Original issue: #10656
- PR: tikv/pd#10657, pingcap/kvproto#1460