Enhance error handling and reporting for app data deserialization

[jmg-duarte]

Description

When users provide app data with wrong partner fees, we get less than good error reporting, for example:

{"errorType":"AppDataInvalid","description":"app data has the wrong format: data did not match any variant of untagged enum Helper at line 1 column 232"}

This is, not only a pain for us to debug but also for the user:

• For us because the special deserializers are all named Helper
• For the user because of the bad error message

This PR changes the deserialization mechanism in a "non-obvious" way to provide proper error messages, as untagged enums stand very much against them.

For example floating point bps are unsupported, they returned the previous error; after this PR they return:

{"errorType":"AppDataInvalid","description":"app data has the wrong format: invalid type: floating point `99.0`, expected u64 at line 1 column 128"}

Changes

• Rename the deserializers
• Refactor the deserializers into weird structs (but better for error reporting)

How to test

Unit tests to ensure nothing broke + playground to test the error

curl 'http://localhost:8000/api/v1/app_data \
  -X 'PUT' \
  -H 'accept: application/json' \
  -H 'content-type: application/json' \
  --data-raw '{"fullAppData":"{\"appCode\":\"YOUR_APP_CODE\",\"metadata\":{\"partnerFee\":[{\"recipient\":\"0x28c716bC23ed77CAEc27f476A366318ad5F12d58\",\"volumeBps\":99.5},{\"priceImprovementBps\":9900,\"recipient\":\"0x28c716bC23ed77CAEc27f476A366318ad5F12d58\",\"volumeBps\":100}]},\"version\":\"1.14.0\"}"}'

[gemini-code-assist]

Code Review

This PR improves deserialization error handling by replacing #[serde(untagged)] with more explicit logic, which is a sound approach. The changes are well-implemented and achieve the stated goal of providing better error messages. The suggestion to simplify the implementation for PartnerFees by leveraging the serde_with crate is valid and would reduce code complexity.

[MartinquaXD]

Looks okay to me.