Fix inactive-share delete writing shares table as parent_table_handle

[sausagee]

Bug

CurrentDelegatorBalance::get_inactive_share_from_delete_table_item wrote two different parent_table_handle values for the same inactive-share delete:

• History row (delegator_balances): inactive-pool table handle (inactive_pool_handle)
• Current row (current_delegator_balances): shares table handle (table_handle)

The write path stores the inactive-pool handle on both rows. get_staking_pool_from_inactive_share_handle / get_by_inactive_share_handle later look up current_delegator_balances.parent_table_handle.

After a withdraw/unlock that deletes the last inactive shares for a delegator, the current snapshot is overwritten with the shares-table handle. Later transactions that resolve pool_address via that parent handle miss the mapping (or hit a different row). That is snapshot corruption and can drop subsequent inactive-share writes (the skip path already tracked in #35).

This is the same two-layer mapping as the write path (shares table → inactive pool table → staking pool). Active-share delete correctly uses table_handle for parent because there is only one layer. The inactive delete path copied that assignment.

Not covered by open PRs #16–#47. #35 is the write-path lookup Err → Ok(None) skip; it does not change this field. Upstream aptos-labs/aptos-indexer-processors-v2 still has the same delete-path assignment.

Root cause

Copy-paste from get_active_share_from_delete_table_item, where parent_table_handle == table_handle is correct. For inactive shares those handles differ: table_handle is the per-delegator shares table; parent_table_handle must stay the inactive-pool table.

Fix

• Shared inactive_share_rows constructor used by write and delete.
• Current delete row now stores inactive_pool_handle, matching history and write.

Test plan

• cargo test -p processor --lib processors::stake::models::delegator_balances — 2 passed:
  • delete_current_row_uses_inactive_pool_parent_handle
  • write_and_delete_agree_on_parent_table_handle
• cargo clippy -p processor --all-targets -- -D warnings (rust-toolchain 1.85)

SHA: aaa8122

CI on this SHA

On-PR jobs that exercise this change:

• Integration-tests — success
• Build (processor image) — success

Pre-existing failures, same class as #16 / #17 / #18 / #20 / #25 / #34 / #35 and unrelated to this diff:

• Rust lint: cargo +nightly xclippy fails compiling third-party allocative 0.3.4 (conflicting implementations of trait Allocative for type ! after nightly unified Infallible and !). Local clippy on rust-toolchain 1.85 is clean.
• BuildAddressReputationApi: Debian 11 apt-get 404s for linux-libc-dev_5.10.262-1 while installing libdw-dev in Dockerfile.address-reputation-api. This PR does not touch that Dockerfile.

No workspace-level diesel/postgres or SDK postgres_full / testing_framework features were added.

Aikido SAST was invoked; the MCP required a user sign-in (/aikido:setup) so the scan did not complete in this environment.

Out of scope

• Fix address_reputation fund double-count on checkpoint replay #16–Fix transfer-row non_transferrable_by_owner copying is_soulbound #47 already-open fixes
• Inactive-share write-path lookup skip (Fix inactive-share skip when pool-address lookup fails transiently #35)
• TableFlags (Write historical token_datas_v2, token_ownerships_v2 and fungible_asset_balances to Postgres #10)