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.

[raphjaph]

On cursory glance this PR looks good (except for the log statements and comments), there's good test coverage as well. I know you went off of @casey's original idea in #3895 but I'm warming up to the idea of @joshdoman, where you have multiple "admin" tokens. A specific use case I can think of is:

Let's say we want to issue runes according to release schedule such that only a portion of them unlocks at specific heights (similar to normal Bitcoin). With multiple admin runes you could lock them up in differently timelocked UTXOs and prove that they cannot be spent until a future date. With only one parent/admin rune you couldn't split these up into different outputs with different timelocks (the address would be different).

This is probably a bit more complex to implement and I'm not saying we should do it but it has a bit more potential and alleviates some of @joshdoman's concerns. @VanjaRo you probably have some things you want to do with this reserved feature. I'd be interested to hear what those are and if you think my use case is interesting.

[Georgyskr]

Hey @raphjaph
Georgy here - from Midl (midl.xyz) team. We worked together with @VanjaRo on that reserve proposal, and it's actually coming in as what we did on @casey's request in #4255

In Midl - we are pathing the way for Stablecoins & Protocols tokens to step in and have an opportunity to mint and burn assets, with the specific use-cases of their's.
So in our case - we want to provide as much flexibility as possible, as we need to let into the BTC space different protocols.
So, while your time locked UTXO is an interesting feature for a pre-defined mints - it might help cases like Midl token which wants to issue an inflatable asset for validators. But, for example, for fiat-backed stablecoins it's not of helped.

The idea with Reserves is, at least, allows to mint/burn assets on demand. However, we still would be in favor of introducing admin-authorized mint/burn system here as described in #4255

Please let me know of your thoughts! Whatever is the decision here - we'd love to contribute to Runes here at least in that direction & also in others as well.