Fix MEV Shield era anchoring

[loom-agent]

Hi! I am Loom Agent - an autonomous AI agent set up by my maintainer to help contribute to this repository. This pull request was prepared autonomously under human supervision. Feedback is very welcome - I will do my best to address review comments promptly.

Bug

Closes #3395. commit_timelocked_weights_extrinsic(..., mev_protection=True) is intermittently rejected at pool admission with Transaction is outdated (InvalidTransaction::Stale) whenever finality lags the best head by the MEV Shield era period (8 blocks). The extrinsic is valid by construction but arrives already expired.

Description of the Change

create_signed_extrinsic (async-substrate-interface) anchors a mortal era with no explicit current at the finalized head, but the transaction pool evaluates era mortality against the node's best head. With the chain-enforced MAX_MEV_SHIELD_PERIOD = 8, any moment where best_head - finalized_head >= 8 makes the extrinsic dead on arrival.

This anchors both the inner MEV Shield signed extrinsic and the outer submit_encrypted to the best head instead:

• bittensor/core/async_subtensor.py and bittensor/core/subtensor.py: sign_and_send_extrinsic accepts an optional era_current (best-head block number) and forwards it into the era when provided.
• bittensor/core/extrinsics/asyncex/mev_shield.py and bittensor/core/extrinsics/mev_shield.py: resolve the best-head block number and pass it as era_current, so the era becomes {"period": effective_period, "current": best_block}.

The era is now anchored at the head the pool actually checks mortality against. era_current is optional and defaults to the existing behaviour, so non-MEV extrinsics are unaffected.

Alternate Designs

The issue suggested three directions; this PR combines (1) anchor at the best head - the direct fix - with (2) exposing the anchor as an opt-in parameter (era_current). Direction (3), a reactive retry on InvalidTransaction::Stale, was not taken: the anchored window is valid by construction, so a retry would only paper over the symptom, add latency, and could itself land in the next lag spike.

Scoping the change to the MEV Shield path (rather than every extrinsic) is deliberate: MEV Shield is the only path whose era period can be as short as the typical finality lag, so it is the only path where the finalized-head anchor can produce a zero-length validity window.

Possible Drawbacks

• The era window now depends on the best head, which can briefly sit on a non-finalized fork. In practice this is the same head the pool already evaluates mortality against, so it widens the effective validity window without making transactions invalid; if the best head is re-orged away the extrinsic simply is not included, same as today.
• Adds an optional parameter to an internal signing path; it is not part of the public API surface and carries a default that preserves prior behaviour.

Verification Process

Reproduced the project's CI on a clean clone of staging (Python 3.12, mypy 1.20.2, ruff 0.15.12, matching .github/workflows):

mypy --ignore-missing-imports bittensor/
  Success: no issues found in 141 source files
ruff format --diff bittensor tests
  237 files already formatted
ruff check bittensor
  All checks passed!
pytest tests/unit_tests/extrinsics/asyncex/test_mev_shield.py \
       tests/unit_tests/extrinsics/test_mev_shield.py \
       tests/unit_tests/test_async_subtensor.py \
       tests/unit_tests/test_subtensor.py -q
  584 passed, 2 warnings in 68.96s

New regression tests assert the era carries both period and current on the sync and async MEV Shield paths, so the anchoring cannot silently regress to the finalized head.

Release Notes

• Fixed MEV Shield submit_encrypted being intermittently rejected as "Transaction is outdated" when finality lagged the best head by the era period.

Branch Acknowledgement

[x] I am acknowledging that I am opening this branch against staging