Resolve a WAVE name at the mark's own block, not at lookup time (HashMark §7.6 form 2)

[Zyrtnin]

HashMark §7.6 names two acceptable ways to relate a mark to a name. #594 implements form 1 (present tense, stated separately). This issue is form 2, which the protocol author describes as the real fix and as what actually solves the altered-contract case.

Why form 1 is not the end state

A name resolves to whatever it points at now; a mark was made at a past block. Form 1 is honest about that but cannot answer the question a recipient actually has. Form 2 can:

Establish what the name pointed at at the block that carried the mark, by fetching and verifying the chain of modification transactions that changed its target. Then "recorded by the holder of company.rxd at that time" is a sound statement.

And the constraint that shapes the design:

An implementation must not take a name-service index's word for a historical target. That is an unverified claim standing behind an identity statement, which is the inversion this protocol avoids everywhere else (§2.8).

What pyrxd has, and what it lacks

• Has: build_mutable_nft_script / extract_payload_hash_from_commit_script; ref-walking in glyph/dmint/chain.py as a precedent for verifying a chain of transactions rather than trusting a summary; the mark's block height on the --fetch path.
• Lacks: any mod-history walker. WaveResolver.resolve() (glyph/wave.py) goes through RxinDexerClient — an index — which is exactly the source §7.6 forbids for a historical target.

Sketch

1. Resolve the name to its glyph ref (index is fine here — a present target is re-verifiable against the chain, per §2.8's re-fetch rule).
2. Walk that glyph's chain of mod transactions backwards, verifying each on chain rather than accepting an index's ordering.
3. Select the target in force at the mark's block height.
4. Report recorded by the holder of <name> at block N only when every step verified; otherwise fall back to form 1 and say why.

Boundaries worth fixing now, before code exists

• A pasted script has no block, so form 2 is unavailable there by construction — it must degrade to form 1, not to silence.
• Failure must degrade, never upgrade. An unwalkable history is form 1 plus a reason; it must never produce a bare "verified" that reads stronger than the evidence.
• Reorg depth matters. A target established at a height inside the reorg window is provisional and should say so.
• The honest-path test is the one to write first: a name that has never moved must still resolve, or this refuses valid work for the overwhelmingly common case.

Not urgent, but not cosmetic

Form 1 is what §7.6 prescribes in the interim, and it is shipped. This is the difference between "here is a name, draw your own conclusion" and answering the recipient's actual question.

Depends on #594.