Add "In reserve" Rune Field

[VanjaRo]

This PR implements a new "in reserve" field, referenced in this issue #3895. This field represents the amount of runes held at the same address as the parent inscription. This feature helps users distinguish between the total supply and the portion that's still controlled by the original creator/issuer.

Key Changes:

• Added a new reserved field to the Rune structs in API responses
• Implemented calculate_rune_reserved helper function to determine the reserved amount
• Updated HTML templates to display reserved supply separately from circulating supply

Implementation Details

The "in reserve" calculation works by:

• Finding the parent inscription of a rune
• Determining which address holds that parent inscription
• Iterating through all UTXOs (outputs) owned by that address to find balances of the specific rune
• Summing up all found balances to calculate the total reserved amount

No changes to the index structure were made. Currently, scans all address outpoints rather than using a direct lookup mechanism.

Test Coverage

Implemented several server tests:

• rune_without_parent_shows_no_reserved_supply –– runes without parent inscriptions
• rune_shows_reserved_supply –– runes with parent inscriptions
• rune_reserved_supply_changes_when_transferred –– the reserved calculations logic is correct

Open to comments and suggestions :)

[joshdoman]

This is really interesting. I'm going to withhold comments on the precise implementation, but I have three questions regarding the design in general:

1. Do you think it's wise for the rune protocol to be reliant on tracking ownership of inscriptions? As of right now, there's a nice separation between runes and inscriptions, and you can index one without indexing the other, without losing functionality. The way this feature is implemented, users would have to index inscriptions in order to know the reserve status of a rune.
2. Is there a risk that users will mistakenly think runes are reserved, when they are not? As an example, a user might create a rune with an inscription, not knowing that whoever owns that inscription in the future will automatically designate runes held at the same address as "reserved." ord might then display balances as reserved unintentionally.
3. In that vein, is there a risk that the "reserved" balance accidentally increases? I'm thinking of a scenario where "issued" runes are held at an address, which then receives the inscription, accidentally or not. Those "issued" runes would then inadvertently be "unissued", correct? Is that type of behavior expected? It feels very spooky-action-at-a-distance.

Not saying any of these questions should hold up this PR. I just need help thinking them through.

Follow up
As for (1), I imagine an alternative approach could be implemented, which gives the power to designate the "reserved" balances to the owners of another rune, rather than an inscription. This would keep rune-related features purely in-protocol, but it does add a small degree of complexity. Namely, you would need a new even tag to designate the "reserver" rune, and you would need the reserver rune to be non-upgradeable, so that users always know which balances are reserved, and which aren't.