Improve default `dataTooltip` with richer information from adapted payloads

**Context** When a track has no `kind` and no `dataTooltip`, the resolver synthesizes a minimal `fields` spec from the common feature-shaped record (`type`, `description`, `start`/`begin`, `end`) — see `src/tooltips/resolve.ts`. This is a reasonable floor, but it throws away a lot of information that adapters actually produce into the payload: scores, cross-references, sequence context, consequence types (for variants), AlphaMissense pathogenicity bands, and so on. Authors who haven't yet written a custom `dataTooltip` see a visibly impoverished tooltip compared to the old hard-coded ones, even when the adapter has clearly populated richer fields. Goal: make the default tooltip pull more from what's already on the payload (including fields emitted by `calculate` transform steps) so that an out-of-the-box config produces a useful tooltip without the author writing one. **Task** Expand the default tooltip synthesizer in `src/tooltips/resolve.ts` to surface more of the adapted payload automatically, and render it via the Markdoc path so formatting (links, emphasis) matches custom tooltips. **Scope:** * Extend the fallback field list beyond `type`/`description`/`start`/`end` to include, where present: `score` (formatted per-kind), `consequenceType`, `clinicalSignificances`, `xrefs` (as linkified names where a source→URL map exists), `evidences` (count + first source), and any fields added by `calculate` steps. * Emit the fallback through the Markdoc renderer rather than a flat `<h5>/<p>` grid, so that (a) links become anchors with the same URL-scheme allowlist as author-written tooltips, and (b) the visual treatment matches when authors progressively customize. * Preserve the existing precedence: any `tooltipContent` the adapter stashed on the item still wins; any author-written `dataTooltip` still wins over the default. * Document the expanded fallback set in `specs/config-approach.md` under the "Sensible out-of-the-box fallback" bullet in the Accessibility section. List the fields surfaced, in what order, and with what formatting. * Add a snapshot/DOM test covering: variant record → expected default tooltip, feature record with xrefs → expected default tooltip, minimal feature record → same minimal tooltip as today (no regression). **Notes:** Keep the fallback compact — this is a safety net, not a replacement for authored tooltips. If the payload has fifteen fields, surface at most ~six; the rest are the author's call to include with an explicit `dataTooltip`. Pick the subset based on which UniProt/AlphaFold/variant adapters actually populate the fields — don't infer from type heuristics alone.