feat(platform): add GetShieldedNotesCount query for sync progress

[QuantumExplorer]

Issue being fixed or feature implemented

Wallets have no cheap way to learn the total number of notes in the
shielded pool. During a shielded sync the client streams note chunks
but can't show a determinate progress bar because it doesn't know the
denominator (total notes) until it has fetched everything.

This adds a query returning the current leaf count of the shielded
notes commitment tree (= total notes). A wallet calls it once at the
start of a sync to seed a progress-bar denominator
(notes_total → mmr_chunks_total → percentage).

Extracted as a standalone PR from the broader shielded-sync work so it
can land and deploy independently — the interleaved-streaming and
dual-progress-bar changes depend on this query existing on-chain.

What was done?

GetShieldedNotesCount, wired end-to-end and proved (mirrors its
sibling GetShieldedPoolState):

• proto (platform.proto): request carries prove: bool; response
  is oneof result { uint64 total_notes_count; Proof proof }. Plus
  dapi-grpc codegen registration (added to VERSIONED_RESPONSES) and
  regenerated JS/web/nodejs/java/objc/python clients.
• drive-abci handler at query::shielded::notes_count (+ v0) with
  proved/unproved branches and tests; gRPC route in service.rs.
• drive verifier verify_shielded_notes_count (+ round-trip tests)
  and its verify_shielded_notes_count FeatureVersion slot.
• platform-version: notes_count query slot (v0/v1/v2_test all
  (0,0,0)); no protocol bump.
• rs-dapi-client transport route + rs-dapi drive_method! arm.
• drive-proof-verifier: ShieldedNotesCount(pub u64) + FromProof.
• rs-sdk: Fetch + FetchCurrent (proved), Query honoring
  prove, and helper
  platform::types::shielded::fetch_shielded_notes_count(&sdk).

Why it's provable

The on-chain notes tree is an
Element::CommitmentTree(total_count, chunk_power, flags). total_count
is the element's first field and its serialized bytes are hashed into
the Merk value hash, so the app/root hash binds it — grovedb's own
comment: "total_count and height … are already authenticated by the
Merk value hash." The proved path issues a single-key PathQuery at the
shielded pool path (no subquery), so GroveDB returns the serialized
CommitmentTree element and the verifier decodes total_count (field
0) against the verified root. Same mechanism GetShieldedPoolState uses
for its stored balance.

How Has This Been Tested?

• cargo check -p drive -p drive-abci -p dash-sdk -p drive-proof-verifier — clean.
• cargo test -p drive-abci --lib query::shielded::notes_count — 3 passed
  (none-version → decoding error; unproved → value; proved → proof).
• cargo test -p drive --lib verify::shielded::verify_shielded_notes_count — 3 passed (round-trip: 0 on fresh state, N after inserts).
• cargo test -p drive-proof-verifier --lib shielded_notes_count — 1 passed.
• cargo fmt --all --check — clean.
• gRPC clients regenerated via yarn workspace @dashevo/dapi-grpc build.

Breaking Changes

None. Additive query; new version slots initialized to 0/(0,0,0),
no protocol-version bump. Existing clients unaffected; nodes must deploy
this build to answer the new query.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added a new getShieldedNotesCount endpoint to query the total count of shielded notes in the platform.
  • Users can optionally request cryptographic proof to verify the count.
  • Integrated SDK support for fetching shielded notes count data.