Add TTM revenue and tighten metric semantics

[rameerez]

Summary

This PR started from adding trailing-twelve-month revenue to profitable, but it also includes a broader metric audit against the current pay data model.

It adds TTM revenue, adds denominator-explicit valuation helpers, makes revenue metrics net of refunds, tightens trial / subscriber / first-monetization semantics, hardens status handling against current Pay lifecycle variants, updates the built-in dashboard, and expands both the README and inline code comments for future maintenance.

The latest pass also makes the founder-facing API a bit friendlier with Profitable.ttm as a shorthand alias for ttm_revenue, documents the processor support boundary more explicitly, and removes the large standalone test-helper mirror by extracting shared metric logic into a single implementation file that both production code and tests load.

Main Changes

• add Profitable.ttm_revenue
• add Profitable.ttm as a founder-friendly alias for ttm_revenue
• add Profitable.revenue_run_rate
• add Profitable.estimated_arr_valuation
• add Profitable.estimated_ttm_revenue_valuation
• add Profitable.estimated_revenue_run_rate_valuation
• keep estimated_valuation as a backwards-compatible ARR alias
• make revenue calculations net of refunds when amount_refunded is present
• count new_customers from first monetization date instead of signup date
• count new_subscribers / new_mrr from billable start, not free-trial start
• keep grace-period subscriptions billable until ends_at
• handle status variants like on_trial, cancelled, and deleted
• exclude metered Stripe items from fixed MRR / ARR run-rate calculations
• surface TTM revenue in the built-in dashboard
• document metric distinctions, valuation denominator semantics, processor support boundaries, and maintenance-critical decisions
• extract shared metric logic to lib/profitable/metrics.rb so the standalone test harness exercises the real production implementation instead of a mirrored module copy
• add extensive regression coverage around trials, refunds, churn windows, summaries, status variants, metered items, processor amount parsing, and the new .ttm alias

Validation

• bundle exec rake test
  • 308 runs, 449 assertions, 0 failures
• bundle exec appraisal pay-11.0 rake test
  • 308 runs, 449 assertions, 0 failures
• bundle exec appraisal pay-7.3 rake test
  • 308 runs, 449 assertions, 0 failures
• bundle exec appraisal rails-7.2 rake test
  • 308 runs, 449 assertions, 0 failures

Draft Status

Still leaving this as draft until the full CI matrix runs and we decide whether to widen processor coverage further or keep the current support boundary explicit in docs.