fix(consensus,framework,actuator): use Locale.ROOT for case-insensitive

[halibobo1205]

Summary

Fix a locale-dependent code hygiene issue: no-arg String.toLowerCase() / toUpperCase() calls use the JVM default locale, and under a minority of locales (tr/az) the folding of 'I' diverges from every other locale. Switching uniformly to Locale.ROOT decouples the behavior from the deployment environment, backed by a compile-time guard and a one-time data normalization.

This PR does three things:

1. Correctness. Replace every no-arg toLowerCase() / toUpperCase() call with its Locale.ROOT counterpart so that string folding is independent of the JVM's startup locale.
2. Defense-in-depth. Enable ErrorProne's StringCaseLocaleUsage checker at ERROR level, and add a custom StringCaseLocaleUsageMethodRef checker to cover the String::toLowerCase method-reference form that upstream misses. Any future no-arg call fails compilation.
3. Data hygiene. MigrateTurkishKeyHelper runs once at Manager.init() to normalize any non-ROOT legacy keys that may exist in AccountIdIndexStore.

What this fix really does

Make the case-insensitive index behavior a pure function of the input bytes, no longer implicitly dependent on the JVM's startup locale. Before this fix, AccountIdIndexStore was, in principle, "case-insensitive relative to whichever locale this JVM happens to use" rather than truly locale-independent. After the fix it is the latter.

This is a data-structure-level correctness convergence — remove an implicit environment dependency and align the implementation with the intended semantics.

Scope

Only one site reaches persistent storage: AccountIdIndexStore.getLowerCaseAccountId — the lowercased result becomes a DB key. All other touched call sites (DB engine selection, disabled-API list, log topic classification, hex display, OS detection, etc.) are in-process runtime comparisons — they neither write to disk nor cross nodes.

The input domain itself is tightly constrained: input to setAccountId is gated by validReadableBytes to printable ASCII (0x21–0x7E). Within this domain, the locale divergence in lowercase only manifests on a single character; every other character (letters, digits, symbols) folds identically under any locale.

Auditability of the migration scope

The "only one site reaches persistent storage" claim above can be independently verified by inspection. Every other touched call site falls into one of:

• (a) Runtime engine selection — dbEngine.toUpperCase() in TronDatabase, TronStoreWithRevoking, TxCacheDB. Locale only affects which DB engine the running process selects; it is never written to disk.
• (b) In-memory config/membership checks — disabledApiList, HttpMethod string comparisons in Util / access filters, Account.accountType switch. Comparison results are consumed in-process and never persisted.
• (c) Display/formatting — Hex.toHexString().toUpperCase() in DataWord, help-text formatting in Args. Output to logs/console, never read back.
• (d) Host-environment probing — os.name / os.arch / java.vendor reads in Arch, WalletUtils.getDefaultKeyDirectory, KeystoreFactory. Local environment branching never crosses nodes.

None of these reach disk or cross-node boundaries, so the migration scope (AccountIdIndexStore only) is exact, not approximate.

Why MigrateTurkishKeyHelper is bundled in

A code-only fix does not fully cover "nodes that were ever started under a non-default locale" — such nodes may carry legacy-format keys in their DB. The cleanest way to keep the code fix and the data state in sync is a one-shot normalization at startup.

Design notes:

• Follows the MoveAbiHelper pattern, gated by a TURKISH_KEY_MIGRATION_DONE flag in DynamicPropertiesStore so it runs at most once.
• Full-table scan (AccountIdIndexStore is a sparse index with very low cardinality — only 14 entries on mainnet today; scan cost is negligible).
• For each non-ROOT-form key: write a new entry under its ROOT-form key, then delete the legacy one.
• Conflict policy: if the ROOT-form key already exists, keep the ROOT entry and drop the legacy value — simple, auditable, and equivalent to the state of a node that was never affected.

For nodes that were never affected, the scan yields zero candidates and the helper is a no-op.

Why the simplified normalization strategy

In principle one could enumerate every possible legacy variant of each ROOT-canonical key and merge them, but that enters a combinatorial space (per-key variant count can reach 2^k, where k is the occurrence count of the divergent character). Even with full enumeration, picking the correct value across conflicts requires knowing the historical insertion order — information the DB layer does not retain.

The conservative strategy chosen here:

• Simple and auditable
• Post-migration local semantics equal those of a node that only ever ran under ROOT
• In the extremely rare conflict case, one legacy value may be dropped — an acceptable cost under case-insensitive index semantics

Impact

• Mainnet / Nile. Safe to include in any normal release. The code changes produce no byte-level behavioral difference in the expected locale environment; the migration scans a trivially small table and is a no-op for nodes that were never affected.
• Node operators. You'll see a one-time migration line in the startup log; it won't run again on subsequent restarts.
• Long term. The ErrorProne rule ensures no future patch can reintroduce no-arg lowercase/uppercase.

Note for downstream fork chains

A downstream fork chain needs to treat this PR as a non-transparent upgrade only if both of the following hold:

1. All of its consensus nodes have historically run under the same minority locale that diverges in lowercase (e.g. all on tr/az).
2. Its history includes a committed SetAccountId transaction whose accountId contains a character that triggers the locale divergence (e.g. I).

On such a chain, the AccountIdIndexStore historical state was produced under non-ROOT folding; after this PR, has() lookups for the same accountId may yield different verdicts, which requires a coordinated hard-fork activation height and operator-defined historical data migration strategy.

Mainnet and Nile are not in this category: condition (1) has never held historically.

Release scope

• Ship as a normal release — no extra coordination required.
• The ErrorProne rule takes effect with this PR; any no-arg lowercase/uppercase in future patches will be blocked at compile time.

[alan-eth]

The test design is really crisp — 14 realistic accountIds covering both divergent (I-containing) and non-divergent names, symmetric pre-/post-migration assertions, and using Locale.forLanguageTag("tr") to faithfully reproduce legacy behavior is lovely. 🎯

One branch that doesn't get exercised today: the if (ArrayUtils.isEmpty(existing)) guard in MigrateTurkishKeyHelper.doWork(). Because this setup only seeds Turkish-form keys and never seeds a pre-existing ROOT-form key for the same accountId, the conflict-recovery path (where a ROOT entry already exists and the legacy Turkish value is silently dropped) is always skipped. That branch encodes the conservative conflict policy you describe in the PR body — would you consider adding a small case that:

• puts a ROOT-form key for "ISSRWallet" with one address,
• then puts the Turkish-form key "ıssrwallet" with a different address,
• runs doWork(),
• asserts the ROOT value wins and the Turkish-form key is gone?

It would also make the intentional policy visible to future readers who might otherwise wonder whether a "keep legacy" policy would be safer.

[halibobo1205]

Thanks — I considered this carefully and want to keep the test surface as-is.

The conflict branch only fires when the same accountId is committed to the DB under both Turkish-form and ROOT-form. For that state to exist on any deployed node, the node would have had to either ：
(a) switch locale mid-operation while remaining in consensus,
(b) restore a tr-locale snapshot onto a ROOT-locale node.
Both of which would have produced contradictory SetAccountIdActuator.validate() verdicts versus the rest of the network and forked the chain. Mainnet and Nile have not observed such a fork, so no deployed DB contains the state this branch handles.

The branch itself stays in the code as a defensive check (snapshot-stitching tools, debugging operations, etc., should still not corrupt ROOT entries), but exercising it in a unit test would document a behavior that production data can never actually reach. I'd rather keep the test suite focused on the paths that real DBs traverse.

[lxcmyf]

Review findings：

[yanghang8612]

The three-layer fix is well-shaped: Locale.ROOT substitution is byte-for-byte neutral within the input domain established by the PR description (the only ASCII codepoint that diverges across locales is I, only on tr/az), the ErrorProne StringCaseLocaleUsage rule plus the custom StringCaseLocaleUsageMethodRef checker close the regression door at compile time (including the method-reference form upstream misses), and MigrateTurkishKeyHelper — gated by TURKISH_KEY_MIGRATION_DONE, modelled on MoveAbiHelper, with a documented conflict policy — is the right shape for the only persisted site.

One angle worth recording in the PR body for future readers: the "only one site reaches persistent storage" claim is independently verifiable by inspection. Every other touched call site is one of (a) runtime engine selection (dbEngine.toUpperCase() in TronDatabase / TronStoreWithRevoking / TxCacheDB), (b) in-memory config or membership checks (disabledApiList, HttpMethod comparisons, accountType switch in Account), (c) display/formatting (Hex.toHexString().toUpperCase() in DataWord, help-text formatting in Args), or (d) host-environment probing (os.name / os.arch / java.vendor in Arch, WalletUtils, KeystoreFactory). None of these reach disk or cross nodes, so the migration scope is genuinely exact rather than approximate — worth a one-liner in the description so the audit is auditable later without re-running the sweep.

LGTM once the remaining NITs resolve.

[halibobo1205]

@yanghang8612 Thanks for the detailed audit and the clean (a)–(d) categorization — updated the PR description accordingly.