accounting: resolve a Resource's persisted cost_class in estimate once it carries a concrete resource reference

## Context

Conditional follow-up noted in **ADR-0333** (landed via #1099). #1099 kept `accounting.estimate`'s `cost_class` caller-supplied (non-breaking) and documented it as a hypothetical priced-against class, because the estimate carries **no** resource selector — billing resolves the booked Resource's persisted class at admission (`ledger._cost_class`).

**Deferred, conditional:** ADR-0333 states that *if the estimate ever grows a concrete resource/allocation reference*, resolving and preferring that Resource's persisted `cost_class` on the read-side becomes the right behavior. It was out of scope for #1099 (would add a breaking resource-lookup surface to a pure price for a `priority:low` clarity gap).

## Precondition (why status:blocked)

This work only makes sense **after** `accounting.estimate` is given a concrete resource/allocation selector. Until then there is no persisted class to resolve. Tracking it here so the decision isn't lost in the ADR.

## What to do (when unblocked)

- When an estimate references a concrete Resource/Allocation, resolve and prefer that Resource's persisted `cost_class` over the caller-supplied hypothetical.
- Keep the caller-supplied `cost_class` as the fallback for selector-less (purely hypothetical) estimates.

## References
- ADR-0333 `docs/adr/0333-estimate-cost-class-hypothetical.md` (§ Alternatives considered)
- Originating issue #1099, `BLACK_BOX_REVIEW.md` F8

Start by reading ADR-0333, especially its “Alternatives considered” section, then inspect accounting.estimate and the originating issue #1099. This work is blocked until estimates have a concrete Resource or Allocation selector; once that exists, done means persisted Resource cost_class is preferred while selector-less estimates retain the caller-supplied fallback.

Written by the indexing model from the issue text.