refactor(be): allocate application numbers from a monotonic cell

[sea-snake]

Design: #4222. Overview: #4230.

ApplicationNumber is derived from lookup_application_with_origin_memory.len(), which is only safe while nothing is ever removed. Once an application can be removed, len() collides with a live number rather than merely reusing a retired one:

applications {0, 1, 2} exist        len() == 3
remove 1                            len() == 2
next new origin is assigned 2       already owned by a live application

Both origins would then share one account universe: every (anchor, 2) reference list and config list would belong to both.

Numbers now come from a monotonic StableCell<u64> at memory index 33. The counter is what guarantees a number is never reissued, because it only climbs — a number it has passed is not offered again even after that application's list is retired.

The counter cannot be the whole answer on its own, because it postdates the applications numbered before it existed. So allocation takes max(counter, highest_stored + 1), and the map being keyed by ApplicationNumber means last_key_value gives that highest number exactly, holes in the lists or not. Nor can the floor stand alone: removing the highest list walks it backwards, which is what the counter is there to prevent.

Both steps are checked and refuse at the ceiling rather than saturating, for the reason allocate_account_number refuses — the number keys both the application list and the origin index, so reissuing one puts two origins on a single list. allocate_application_number and lookup_or_insert_application_number_with_origin return Result for that; all three production callers propagate.

ApplicationNumber never appears in internet_identity.did, so this is invisible to clients.

Rollback needs a release note. The cell at index 33 is exactly what a rollback discards, restoring len() as the allocator over a map that removals have punched holes in. Rolling forward recovers a safe allocator, since the cell can only be raised, but a collision created during the rollback window has already happened.

Tests: application_number_allocator_tests (7). The two the design exists for are a_gap_below_the_highest_number_is_not_handed_out_again — a hole in the lists while the counter is behind, the one state a list count gets wrong — and a_removal_before_the_first_allocation_does_not_collide_with_a_live_number. Both fail if the floor goes back to len().

🤖 Generated with Claude Code

https://claude.ai/code/session_01LVi99RYo2jyi2kCurgovNJ

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to d9034cf.

Security Overview

• 🔎 Scanned files: 4 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/6d3e3b61-710b-4b2b-9c0b-43458b6314b6?scanId=3cf29b1e-2340-4e03-915a-17d77e757060&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Enhancement	► src/internet_identity/src/account_management.rs     Modify set_default_account_for_origin to map errors to SetDefaultAccountError
Enhancement	► src/internet_identity/src/storage.rs     Add NEXT_APPLICATION_NUMBER_MEMORY_INDEX and NEXT_APPLICATION_NUMBER_MEMORY_ID     Introduce next_application_number_memory in Storage and initialize it     Update allocation logic with allocate_application_number to manage application numbers     Use allocate_application_number in lookup_or_insert_application_number_with_origin and related paths     Commentary and error handling enhancements around application number allocation     Extend StorageError with ApplicationsCounterOverflow and ErrorUpdatingApplicationNumberAllocator and corresponding Display text
Enhancement	► src/internet_identity/src/storage/account/tests.rs     Update test to unwrap result from lookup_or_insert_application_number_with_origin
Enhancement	► src/internet_identity/src/storage/tests.rs     Update tests to unwrap results from lookup_or_insert_application_number_with_origin across multiple scenarios

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[aterga]

PR description isn't self-contained.

If apps can be removed, why not store the index of the next-free app ID rather than try to derive from the length of a collection?

Code has changed since