Meta: hazard estimates across gg_survival and gg_rfsrc

[ehrlinger]

Summary

Tracking issue for hazard-estimate functionality across the package. Two existing issues touch overlapping ground:

• calculate hazard estimates (gg_survival) #4 — gg_survival finite-difference hazard from cumulative hazard returns incorrect values (labeled bug + enhancement)
• hazard estimates (gg_rfsrc) #5 — gg_rfsrc has no path to a hazard estimate from rfsrc objects

Both are about exposing $h(t)$ to users, but from different inputs (KM/NA estimates in #4, forest predictions in #5). Worth solving together so the API and visualization are consistent.

Scope

• Definition. Decide which hazard we expose — instantaneous $h(t)$, cumulative $H(t)$, or both — and document the discretization (kernel smoothing vs. finite difference vs. piecewise constant).
• gg_survival (calculate hazard estimates (gg_survival) #4). Fix the finite-difference computation, or replace with a smoothed estimator (e.g. muhaz, kernel on $\Delta H$). Add a regression test against a known-hazard simulation.
• gg_rfsrc (hazard estimates (gg_rfsrc) #5). Derive hazard from rfsrc\$chf (cumulative hazard function) using the same discretization rule as gg_survival. Likely a type = \"hazard\" argument on the existing plot() method.
• Shared helper. Extract the cumulative-hazard → hazard conversion into one internal function so both code paths agree.
• Plot method. plot(gg_*, type = \"hazard\") with sensible y-axis defaults and CI bands where available.
• Vignette example. One worked example per surface (gg_survival, gg_rfsrc) in the survival vignette.

Non-goals

• Competing-risks hazards — separate issue if/when needed.
• Time-dependent covariates.

Open questions

• Smoothing default: kernel bandwidth choice vs. requiring user to pass it?
• Do we want CIs on hazard, or just on cumulative hazard?

Closes #4, #5 when complete.