[flame_manager] `FlameTier` variant names are mislabeled (off by 10x for tiers 3/4/5)

[GideonBature]

Summary

Several FlameTier enum variant names do not match the satoshi value they actually hold. The hardcoded values are correct, so behavior is correct today, but the names are landmines: anyone who later derives the value from the variant name (e.g. via #[display], a doc table, or a refactor) will introduce a denomination bug.

Affected file(s)

• src/inscriptive/flame_manager/flame/flame_tier/flame_tier.rs

Location

src/inscriptive/flame_manager/flame/flame_tier/flame_tier.rs:8-17

pub enum FlameTier {
    Tier1HundredSatoshis,          // 100       ✓
    Tier2ThousandSatoshis,         // 1_000     ✓
    Tier3ThousandSatoshis,         // 10_000    ✗ name says 1k, holds 10k
    Tier4TenThousandSatoshis,      // 100_000   ✗ name says 10k, holds 100k
    Tier5HundredThousandSatoshis,  // 1_000_000 ✗ name says 100k, holds 1M
    Tier6TenMillionSatoshis,       // 10_000_000  ✓
    Tier7HundredMillionSatoshis,   // 100_000_000 ✓
    TierAnyAmount(SatoshiAmount),
}

Confirmed against FlameTier::satoshi_amount() at flame_tier.rs:34-45 and FlameTier::new() at flame_tier.rs:21-32:

Variant	Name implies	Actual satoshi_amount()
Tier3ThousandSatoshis	1,000	10,000
Tier4TenThousandSatoshis	10,000	100,000
Tier5HundredThousandSatoshis	100,000	1,000,000

The byte-level serialization tags (0x01..0x07) and the runtime values are correct; only the human-readable names are wrong. Additionally, the to_bytes() match arms carry inline comments that are also mislabeled (e.g. flame_tier.rs:57 "tier 3 ten thousand satoshis" attached to Tier3ThousandSatoshis), and flame_selection.rs constructs tiers under the same mismatched names (e.g. flame_selection.rs:75,84,93) — which works only because satoshi_amount() is what gets read.

Root cause / analysis

Each tier's numeric value is hardcoded in two places (new() and satoshi_amount()), so the runtime never consults the name. The names were likely written from the previous tier's magnitude and never corrected. The serialization and the matching from_bytes arms are keyed on 0x01..0x07, so the wire format is internally consistent and not affected.

Impact

• No current runtime impact — values are hardcoded.
• High latent risk: future refactors that assume the name describes the value (doc generation, Display impls, parameterizing fees per tier, external tooling parsing debug output) will silently mis-size denominations. This is exactly the category of bug that's hard to catch in review because the names "look plausible."

Suggested fix

Let each variants in the FlameTier enum match the value they are supposed to hold.

References to update (all in src/inscriptive/flame_manager/):

• flame/flame_tier/flame_tier.rs — new(), satoshi_amount(), to_bytes(), from_bytes() match arms and their inline comments
• algorithms/flame_selection/flame_selection.rs:75,84,93 — the three constructed FlameTier:: variants

This is a pure rename — the byte tags (0x01..0x07) and numeric values stay identical, so no migration is needed and on-disk records remain valid.

Checklist

• Rename Tier3/4/5 variants to match their values
• Update all match arms + inline comments in flame_tier.rs
• Update the three construction sites in flame_selection.rs
• Search repo-wide for any other references (e.g. tests, JSON dumps)
• Add/adjust a test asserting each variant's satoshi_amount() matches its name-derived expectation