feat: improve the identification of writeable accounts

[technoch1ef]

Problem

The is_writable closure for V0 (versioned) transactions in extract_instructions_with_metadata only checks whether an account key exists in meta.loaded_addresses.writable:

|key, _| meta.loaded_addresses.writable.contains(key)

This only identifies accounts loaded as writable through Address Lookup Tables (ALTs). Any account that is writable due to its position in the static message header is incorrectly marked as is_writable: false.

By contrast, the legacy message path correctly uses legacy.is_maybe_writable(idx, None), which considers the full message header layout.

How Solana encodes writability in V0 messages

A V0 message's account keys come from two sources, laid out sequentially:

1. Static keys (v0.account_keys) — writability is determined by position relative to the message header:

   • Indices 0..num_signers - num_readonly_signed → writable signers
   • Indices num_signers..num_static - num_readonly_unsigned → writable non-signers
   • The rest of the static keys are read-only

2. ALT-loaded keys (meta.loaded_addresses) — split into .writable and .readonly lists, appended after the static keys

The existing code only handles case 2. Static writable accounts (case 1) are always reported as non-writable.

Fix

The updated closure now checks the account index against the static key boundary:

• If the index falls within the static keys: determine writability from the V0 message header fields (num_required_signatures, num_readonly_signed_accounts, num_readonly_unsigned_accounts), mirroring the logic of is_maybe_writable used in the legacy path.
• If the index falls in the ALT-loaded region: keep the existing loaded_addresses.writable.contains(key) check.

This ensures both static and ALT-loaded accounts have their writability resolved correctly, matching what explorers like Solscan report and what the Solana runtime actually enforces.