feat: expose a stable TRE instance identifier

[nahimterrazas]

Summary

Adds hre.tre.instanceId(): a stable identifier for the specific TRE node the active network points at, and exposes it to upgrades tooling by answering hardhat_metadata on tron-typed networks.

What instanceId() returns

A string that identifies one running TRE instance. It is resolved once and cached per (network, url).

• Container-identity derivation (plugin-managed TRE). When this plugin launched the container (auto-start on hardhat test / node / compile, or a keepRunning restart), the id is 0x + sha256(<docker container id> + "|" + <State.StartedAt>). The container id changes on every fresh docker run and StartedAt changes on every docker start, so the id is distinct for each boot even when the chain is otherwise byte-for-byte deterministic.
• External-TRE fallback + limitation. For a TRE this plugin did not launch (already reachable when a task started, a manual docker-compose up, or a parallel-test runner pointing at its own TRE_URL), the container identity is unknown, so the id falls back to the genesis block hash. Because a TRE booted from identical config reproduces the same genesis block, two deterministic restarts of an external TRE will share an id. This limitation is documented on the API type; let the plugin manage the container lifecycle if you need a guaranteed-fresh id per restart.

This replaces deriving the id from the genesis hash alone, which could not tell two deterministic restarts of the same chain apart.

Provider metadata exposure

An extendProvider hook makes tron-typed networks answer the hardhat_metadata JSON-RPC method, mirroring the built-in Hardhat Network. The response reports the chain id (read from eth_chainId, so it always matches) and the instance id above. Tooling such as @openzeppelin/upgrades-core probes this method to key its per-instance deployment manifests; exposing the id at the shared network provider lets that tooling isolate a restarted local chain's records through its own internal manifest resolution, instead of reusing a manifest keyed by chain id alone. Only tron-typed networks are wrapped; every other network's provider is returned untouched, and no other RPC behavior changes.

Test coverage

• A docker-gated suite boots two fresh TRE instances sequentially, tears each down, and asserts their ids differ while their genesis blocks are identical — the property the genesis-hash derivation could not provide.
• The end-to-end suite asserts the network provider answers hardhat_metadata with a chainId matching eth_chainId and an instanceId equal to hre.tre.instanceId(), and that the external-TRE path falls back to the genesis-derived id.

Both are gated the same way as the existing e2e tests, so CI without a container runtime stays green.