indexer: Process trustline entry changes and store trustline balances

[Copilot]

What

Refactors trustline balance storage to capture complete XDR state (balance, limit, liabilities, flags) from ledger changes and store directly in PostgreSQL, eliminating RPC dependency for trustline queries.

Why

RPC calls for trustline balances create network overhead and latency. By processing ledger changes directly (like Horizon) via a new TrustLinesProcessor, we capture ALL trustline modifications including payments and store complete state in the database. This enables fast, local queries for the most common balance retrieval pattern.

Architecture changes:

• New TrustLinesProcessor: Extracts trustline changes from ledger entries with full XDR fields
• Focused data models: Split monolithic AccountTokensModel into TrustlineBalanceModel and AccountContractTokensModel for separation of concerns
• Schema additions:
  • trustline_balances table stores balance, limit, buying/selling liabilities, flags, last_modified_ledger
  • account_contract_tokens junction table for contract mappings
• GraphQL resolver updates: Trustline balances fetched from DB, only native XLM and SAC contracts use RPC

Query pattern before:

// Required RPC call per trustline
trustlines := GetAccountTrustlines(account)  // DB lookup
for _, tl := range trustlines {
    balance := rpc.GetLedgerEntry(trustlineKey)  // RPC call
}

Query pattern after:

// Single DB query with JOIN, no RPC
balances := trustlineBalanceModel.GetByAccount(account)
// Returns complete state: balance, limit, liabilities, flags

Ingestion flow:

1. Indexer processes ledger changes via TrustLinesProcessor
2. Extracts trustline ADD/UPDATE/REMOVE operations with full XDR
3. BatchUpsert updates database state atomically
4. Checkpoint population streams 30M+ entries in 500k batches for memory efficiency

Known limitations

N/A

Issue that this PR addresses

N/A

Checklist

PR Structure

• It is not possible to break this PR down into smaller PRs.
• This PR does not mix refactoring changes with feature changes.
• This PR's title starts with name of package that is most changed in the PR, or all if the changes are broad or impact many packages.

Thoroughness

• This PR adds tests for the new functionality or fixes.
• All updated queries have been tested (refer to this check if the data set returned by the updated query is expected to be same as the original one).

Release

• This is not a breaking change.
• This is ready to be tested in development.
• The new functionality is gated with a feature flag if this is not ready for production.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.