Function pdf_card_v1 

pub fn pdf_card_v1(
    req: &CardRequestV1,
    stored: Option<&StoredCardV1>,
) -> Result<PdfCardV1, CardServiceError>

Render the printable PDF dope card for a card request.

stored decides where the numbers come from, and it is the whole point of this surface:

• Some(card) — REPRINT. The rows are the caller’s: the stored card.range_table response for this same request. Nothing is solved, bc5d_table_path is never opened, and the footer’s BC, engine version and table version are the stored card’s. A saved card therefore reprints identically after an engine bump, after the correction table at the stored path is overwritten in place, and even after that file is deleted.
• None — SOLVE. range_table_rows runs, i.e. literally the rows range_table_v1 would return for this request, and the footer states THIS build’s version. Unchanged behaviour for a caller that has no stored rows.

Either way this prints a PDF_CARD_KIND card and nothing else: a request carrying a wind card’s wind_speeds/wind_angles_deg, or a stored card of another kind, is refused. Both paths map their rows onto the CLI’s Range/Drop/Wind/Lead dope card, plus the Lead column that CardRequestV1::pdf’s target_speed asks for. The Range column is denominated in the stored/requested distance unit (yards imperial / metres metric), unlike trajectory -o pdf, whose dope card is always yards.

The header/footer block is always imperial, matching both CLI PDF call sites: a metric request’s velocity/temperature/pressure/altitude/wind/weight are converted for display only. The Solver: label reports this build (online with the online feature, otherwise offline) and the timestamp is generation time, so neither is caller-settable — and neither is a number a shooter dials.