fix(svg,line): draw-on paints nothing at zero, and <text> gets a font

[LeadcodeDev]

Closes #374. Closes #376. Refs #388.

#376 — two faults in draw-on

A dot at draw_progress: 0. The paint and dash effect were built before progress was checked, and Skia renders a zero-length dash with a round cap as a dot. Reverting the guard reproduces it exactly: "got 124 lit pixels".

The drawing stroke did not match the finished mark. A leftover set_stroke_width(sw / scale_avg) cancelled the canvas scale that had already been applied, so the stroke stayed the same thickness whatever the node size while resvg's finished render scaled with it — red proof small=4px large=4px across a 4× size change. And stroke-linecap/stroke-linejoin were never read off the SVG, so the last drawing frame's butt cap jumped to the finished frame's round one — red proof drawing_left=10 finished_left=2, an 8 px gap, exactly half the 16 px stroke width.

#374 — <text> was never drawn, and said nothing

usvg::Options::default() ships an empty fontdb::Database. When text-to-path conversion finds no face, usvg drops the <text> node from the tree entirely — and a sibling <rect> renders fine, which is what masks the loss. Parse options now share a process-wide fontdb initialised once with the system fonts. No new dependency: usvg already re-exports fontdb and roxmltree.

The residual gap, stated rather than left to be found. usvg appends a generic serif fallback to its own query, so once any system font is loaded even an unknown font-family resolves — to the wrong face, but visibly, not invisibly. A scenario-declared custom font feeds Skia's FontMgr for the text component, which is a completely separate font engine from usvg's; plumbing one into the other would need a public accessor for "all bytes registered for family X" that does not exist.

What genuinely stays silent is a host with no usable font anywhere. For that, warn_on_unresolved_svg_text compares the <text> count in the source against the resolved count in the tree and warns once per distinct payload rather than once per frame:

Warning: svg: 1 of 1 <text> element(s) have no matching font face for their
font-family and will not be drawn. Declare the family in the scenario's `fonts`
list (a "google" source or a local `path`), or use a font already installed.

usvg does its own log::warn! for a family miss, but nothing here installs a log backend, so that trace is discarded — documented in the rule file rather than fixed, since installing a global logger for a two-line fact is a different change.

Verified independently, because this branch was never pushed

The agent that wrote this reported a full green run but did not commit or push — the work was sitting uncommitted in a worktree. So none of its claims were taken on trust: the diff was applied onto current main and the whole gate re-run here.

cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace (1626) all clean. Comment count still 0.

End to end against the release binary:

	result
12 px line at draw_progress: 0.0	0 lit pixels
<svg> with <text font-family="Helvetica">SVG</text>	1962 dark pixels, where it painted none

My first attempt at that second repro used content instead of data and the validator caught it — "unknown attribute 'content' on 'svg' — it is silently ignored". Worth noting that the attribute checker did its job on my own mistake.

Written comment-free, per the codebase-wide rule from #345.