fix(server): page dotNS pendingClaims through its (address,uint256,uint256) view

[tallesborges]

Fixes #573.

truapi-server now calls DotnsPopController.pendingClaims(address,uint256,uint256) instead of the removed pendingClaims(address). The controller on Paseo Next v2 and PreviewNet was upgraded in place to the paged signature (paritytech/dotns@31dc754), so the old call reverted and resolve_labels dropped every gateway-minted username that had not yet settled through claimLabelStore.

• Pages through the view (16 per page, stops on a short page, warns if the page cap is reached). The contract caps limit at 200.
• decode_pending_claims_array is unchanged; the return type did not move.
• Selector expectation updated ca78533d → 76025b85, with exact calldata coverage.
• runtime/identity.rs scripted controller asserts offset = 0 and 1 <= limit <= 200.

Not changed here: the revert-to-empty fallback in pending_claim_labels, which is what hid this regression. Tracked as the open question in #573.

Verified with cargo test -p truapi-server --lib -- dotns_gateway runtime::identity (21 passed) and cargo clippy -p truapi-server --all-targets -- -D warnings.

After merge, brevity-dozer needs its TRUAPI_REV pin bumped to pick this up.

[pgherveou]

ah man I should have found that earlier starting the exact same PR

[pgherveou]

will fix the flacky CI test and merge @tallesborges