fix(crypto): deprecate events field in shielded TRC20 scan APIs

[Federico2014]

What does this PR do?

Deprecates the events field in shielded TRC20 scan API requests and removes server-side log-type filtering.

1. Marked the events field as [deprecated = true] in IvkDecryptTRC20Parameters and OvkDecryptTRC20Parameters request messages in api.proto
2. Added runtime rejection: gRPC returns INVALID_ARGUMENT, HTTP returns 400 when the deprecated events field is populated
3. Removed topicList parameter from internal method signatures in Wallet, RpcApiService, and HTTP servlet handlers (ScanShieldedTRC20NotesByIvkServlet, ScanShieldedTRC20NotesByOvkServlet)
4. All log types (Mint/Transfer/Burn) are now always inspected during a scan
5. Added gRPC test coverage for the deprecation-rejection path across Full, Solidity, and PBFT stubs

Why are these changes required?

The events field allowed callers to filter shielded TRC20 event classes by passing user-controlled log topic strings that were hashed and matched server-side. This was an unnecessary attack surface — callers should always scan all log types and filter client-side. Removing the field simplifies the API contract and eliminates potential information leakage through selective scanning.

⚠️ Breaking Changes:

• scanShieldedTRC20NotesByIvk/Ovk — the events request field is now rejected outright (INVALID_ARGUMENT on gRPC, HTTP 400). Clients still sending the field must remove it. Clients that relied on the field to limit scan scope will now receive results for all log types.

This PR has been tested by:

• Unit Tests — RpcApiServicesTest, WalletMockTest, ShieldedTRC20BuilderTest
• Build passes (./gradlew clean build)

Follow up

No consensus logic or on-chain state transitions affected.

Extra details

[alan-eth]

Really clean approach to the deprecation — rejecting early before any business logic runs is exactly the right pattern for deprecated fields!

Minor observation: the same events field check appears 8 times across this file and the two servlets (4 in RpcApiService + 2 in each servlet). Would it be worth extracting a tiny static helper like rejectIfEventsPresent(ProtocolStringList events) to keep the rejection message and logic in one place? If the error message ever needs updating, a single change point would be nice. Totally fine as-is though — it's a straightforward guard clause.

[alan-eth]

Love that both doGet and doPost are covered — easy to forget the GET handler in servlet deprecation work!

One subtle difference I noticed: in doPost, the check is !ivkDecryptTRC20Parameters.getEventsList().isEmpty() (protobuf list non-empty), while in doGet, the check is request.getParameter("events") != null. The doGet version will also reject ?events= (empty string), which is slightly stricter than the protobuf-based check. This is probably the right call for a deprecation, but wanted to flag in case the distinction matters for client compatibility.