Refactor UsageProgressBar to support a dedicated forecast overlay

[kmatsunami]

Summary

Refactor UsageProgressBar so it can render a forecast overlay that is distinct from the existing pace overlay semantics.

This issue is about the progress bar API and drawing behavior only. It should not decide when forecast is shown, compute projection math, or format forecast copy.

Scope

• Add explicit forecast-oriented inputs to UsageProgressBar instead of reusing pacePercent for end-of-window projection.
• Preserve the current bar fill for actual usage.
• Render a separate overlay / marker for the forecast end position.
• If the forecast exceeds 100%, cap drawing at the bar end while keeping the API able to distinguish overflow.
• Suppress the visual marker when forecast and current value are effectively the same.
• Ensure highlight / selection rendering still looks correct.

Non-goals

• No forecast math.
• No row visibility decisions.
• No forecast text / copy formatting.

Files likely involved

• Sources/CodexBar/UsageProgressBar.swift
• Any nearby preview / menu-row helper that needs API updates

Acceptance Criteria

• UsageProgressBar has a dedicated forecast API that is not semantically tied to UsagePace.
• The bar can represent in-range forecast and overflow forecast.
• Existing actual-fill rendering remains intact.
• Existing highlighted menu behavior is not visually regressed.