feat(validators): display base_fee in drops on Fee Voting table (#1206)

[tmchow]

High Level Overview of Change

Closes #1206.

Renders validator base_fee in drops on both the Validators Fee Voting table and the Validator detail page's voting tab (for example 10 drops instead of 0.00001 XRP). Reserve voting columns (reserve_base, reserve_inc) keep their XRP formatting because those values are large enough to read as XRP already.

Context of Change

The Fee Voting table's base_fee column goes through renderFeeVoting in src/containers/Network/ValidatorsTable.tsx, which converts the raw drops value to XRP and runs it through renderXRP. For reserve_base and reserve_inc that produces readable amounts (1.00, 0.20), but base_fee defaults to 10 drops and surfaces as 0.00001, which is harder to scan and disconnected from how validator operators actually talk about the reference fee.

The fix gates the XRP conversion on the column's className. When the cell renders the base_fee column, show the raw drops value with a translated drops suffix; otherwise, keep the existing XRP path untouched. The same rule is applied to the base_fee cell on VotingTab.tsx so the individual validator page stays consistent with the table.

I also added a drops string to public/locales/en-US/translations.json. Other locale bundles fall back to the English string via the project's existing fallbackLng: 'en-US' configuration until translators catch up.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (You added tests for code that already exists, or your new feature included in this PR)
• Documentation Updates

Codebase Modernization

• Yes, this PR modernizes the codebase.
• No, this PR does not modernize the codebase.

Before / After

Before: the BASE FEE cell on the validators Fee Voting table and on the individual validator's voting tab rendered 0.00001 for a typical 10-drop reference fee, because the value was divided by DROPS_TO_XRP_FACTOR and formatted through renderXRP. Downward/upward vote indicators still rendered, but the magnitude was hard to read at a glance.

After: the same cells render 10 drops (or whatever drops value the validator is voting for). Vote direction indicators are unchanged. Reserve columns (base, owner) continue to use the XRP formatting because those values are large enough to read as XRP.

Test Plan

• npx jest --env=jsdom --testPathPatterns='Validators|Voting' — 6 test suites, 21 tests passing.
• validatorsTable.test.js now asserts '10 drops' for the td.base_fee cell (was '0.00001').
• VotingTab.test.tsx now asserts '10 drops' for the first .metrics .cell (was '0.00001').
• Manual review of the rendered output against the issue description (small BASE FEE values are easier to scan as integer drops).

Future Tasks

• Add drops translations to the other locale bundles (ja-JP, ko-KR, es-ES, fr-FR, ca-CA, my-MM). Until then those locales fall back to the English string via the project's existing fallbackLng: 'en-US' configuration.

[mvadari]

Please add the null keys in the other languages

[tmchow]

Done in 2cf8686. Added "drops": null to ja-JP, ko-KR, es-ES, fr-FR, ca-CA, and my-MM right after each locale's base_fee key. They keep falling back to the en-US string via fallbackLng: 'en-US' until translations land.