feat(ios): add getExtendedMemoryUsage() exposing resident size and region count

[maxim-smotrov]

Motivation

getMemoryUsage() only exposes iOS phys_footprint (the jetsam-accounted number that matches Xcode's memory gauge). That's the right primary signal, but it's not enough to actually diagnose memory problems in the field:

• phys_footprint hides fragmentation and leaks until it's too late. A steadily climbing region_count (number of VM regions) is an early, reliable indicator of address-space fragmentation or leaked mappings - often visible well before phys_footprint spikes.
• resident_size gives the real physical-RAM picture. It complements phys_footprint (which excludes shared/reclaimable memory) so consumers can tell why footprint is what it is.
• We can expose this for free. The periodic updater already makes exactly one task_info(TASK_VM_INFO) call. These fields come back in the same struct, so reading them adds zero extra native calls or measurable overhead - which matters for a performance toolkit that must stay cheap.

In short: for the cost of reading two extra fields that are already available, this gives advanced consumers the data they need to catch memory regressions early, without changing or slowing down the existing API.

Summary

Adds getExtendedMemoryUsage() to read extra iOS memory stats (resident_size and region_count) along with the usual phys_footprint - all from one native call.

On iOS, the memory buffer grows from 4 to 24 bytes. Offset 0 is still the phys_footprint value, so getMemoryUsage() and everything else keeps working. Android is unchanged; the extra fields just return 0 there.

Buffer layout (iOS)

Offset	Type	Field	Unit
0	Int32	phys_footprint	MB
8	Float64	resident_size	KB
16	Float64	region_count	count

Test plan

• iOS: getExtendedMemoryUsage() returns non-zero resident size and region
  count, and memoryUsageMb matches getMemoryUsage().
• Android: memoryUsageMb works, extra fields are 0.

Important

Changes made with the help of AI, reviewed by a human