feat: add getMemoryStats endpoint to registry

[rvanasa]

This PR adds an admin-only query endpoint that reports entry counts and Candid-serialized byte counts for analyzing what data structures account for the most storage overhead in the registry canister.

getMemoryStats is a query method gated behind Utils.isAdmin(caller). It returns:

• Runtime metrics: rts_heap_size and rts_memory_size from mo:prim
• Per-structure stats: { count : Nat; bytes : Nat } for all data structures across the main actor, DownloadLog, StorageManager, and Users

[Copilot]

Pull request overview

Adds an admin-only getMemoryStats query endpoint to the registry canister to report runtime RTS memory metrics and per-data-structure {count, bytes} estimates (via Candid serialization sizing) for storage overhead analysis.

Changes:

• Extended the public Candid interface with StructureStats, MemoryStats, and getMemoryStats.
• Implemented getMemoryStats in the main canister, including RTS heap/memory metrics and per-structure aggregation.
• Added internal getMemoryStats helpers to DownloadLog, StorageManager, and Users to report their respective structure stats.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
cli/declarations/main/main.did	Adds StructureStats/MemoryStats types and the getMemoryStats service method.
backend/main/main-canister.mo	Implements the admin-only query and aggregates stats across in-canister structures and submodules.
backend/main/DownloadLog.mo	Adds stats computation for download maps, snapshot buffers, and temp records.
backend/storage/storage-manager.mo	Adds stats computation for storage maps.
backend/main/Users.mo	Adds stats computation for the users map.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 11 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 8 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Kamirus]

Suggestion: Extract memory stats logic into a shared module

The sampling logic is duplicated across 4 files (DownloadLog.mo, Users.mo, StorageManager.mo, main-canister.mo) with 6+ near-identical sampling functions. I'd like to keep the domain modules as clean as possible — could we extract the shared logic into a dedicated MemoryStats.mo module?

The idea:

1. New backend/main/MemoryStats.mo — owns everything:

• Type definitions (StructureStats, MemoryStats)
• Generic sampling helpers (sampleMapBytes, sampleBufferBytes, sampleMapOfBuffersBytes)
• The collect(...) function that assembles the full MemoryStats record
• The SAMPLE_SIZE constant

2. Domain modules — each getMemoryStats() becomes a thin wrapper calling the shared helpers:

// Users.mo — before: ~40 lines of inline sampling
// Users.mo — after:
public func getMemoryStats() : { users : MemoryStatsHelper.StructureStats; names : MemoryStatsHelper.StructureStats } {
  {
    users = MemoryStatsHelper.sampleMapBytes(_users, func(k : Principal, v : Types.User) : Blob = to_candid((k, v)));
    names = MemoryStatsHelper.sampleSetBytes(_names, func(k : Text) : Blob = to_candid(k));
  }
};

Similar for DownloadLog and StorageManager — they keep getMemoryStats() because the fields are private, but the actual sampling logic lives in the shared module.

3. Main actor — stays minimal:

public query ({ caller }) func getMemoryStats() : async MemoryStatsHelper.MemoryStats {
  assert (Utils.isAdmin(caller));
  MemoryStatsHelper.collect(
    { packageVersions; packageConfigs; highestConfigs; packagePublications; ownersByPackage; maintainersByPackage; fileIdsByPackage; hashByFileId; packageFileStats; packageTestStats; packageBenchmarks; packageNotes; packageDocsCoverage },
    downloadLog.getMemoryStats(),
    storageManager.getMemoryStats(),
    users.getMemoryStats(),
  );
};

This way:

• The sampling algorithm is defined once, not 6+ times
• DownloadLog.mo, Users.mo, StorageManager.mo each get ~5-10 lines added instead of 40-150
• Changing the sampling strategy (sample size, algorithm) is a single-file change
• The admin helper code is clearly separated from domain logic

[Kamirus]

Go for it, just one nit that might raise some warnings