Track metadata (name, comment, description, number, type) is never parsed

[thomthom]

Track declares and exposes name, comment, description, number and type, but ReadGpxXml in src/cpp/fastgpx/fastgpx.cpp only reads <metadata><name>, <trkseg> and <trkpt>. The <trk> children are never visited, so from Python these attributes are always None.

gpx = fastgpx.load("gpx/test/two-points.gpx")
gpx.tracks[0].name   # None, even when <trk><name> is present

The README example prints track.name, so users will expect this to work.

Suggested fix: read <name>, <cmt>, <desc>, <number> and <type> in the <trk> loop. This is a handful of child() lookups per track, so it does not affect the per-point cost. Note that gpx.name returns '' for an empty <name></name> while a missing element gives None; the same convention should apply to tracks.

Found in the code analysis session; see the other code-analysis issues for related findings.

[thomthom]

Before implementing this, a concern worth recording: fastgpx exists for speed, and the parse
wins so far came from reading less per point (moving the <time> string instead of copying it,
std::from_chars instead of strtod). Adding eager reads runs against that, and the parser
already carries a // TODO: Add parse options, selectively choose what to parse. for exactly this
reason. So the question is whether track metadata should be read unconditionally at all.

What the data looks like

Counted <trk>, <trkseg> and <trkpt> across the 84 GPX files in gpx/:

Set	tracks	segments	points
Recorded rides (2024 TopCamp, Great Roadtrip, Sommertur)	1	4-22	1,173-23,470
third-party/topografix.com/ashland.gpx	11	11	348
third-party/gpxpy/cerknicko-*.gpx	8	8	296
third-party/gpxpy/gpx1.x_with_all_fields.gpx	2	2	1

The realistic files are one track per ~20,000 points, so this is five element lookups per file
against 20,000 points that each already cost several reads. That is a different order of magnitude
from the per-point work that the earlier optimisations targeted.

One wrinkle against that: pugixml's child(name) is a linear scan of the node's children and does
not stop early when the element is absent. A <trk> with 22 <trkseg> children therefore costs up
to 22 node visits per failed lookup, five times over. Still ~110 visits per track against 20,000
points, but it is not literally free, and the worst case is the common one - metadata absent.

Suggested way to settle it

fastgpx_test "[!benchmark][parse]" already covers LoadGpx on two of these files. Implement the
five lookups, benchmark against the previous commit per CLAUDE.md, and only reach for parse options
if the cost actually shows. If it disappears into the noise, the option machinery would be a lot of
design for nothing.

The alternative is to treat the parse-options TODO as a prerequisite and add no further eager reads
until there is a mechanism to opt out, in which case this issue waits on that work.

Still open from the original report

number is std::optional<size_t> and GPX types it as a non-negative integer, so <number>abc</number>
and <number>-1</number> need an answer. Leaving them as None keeps this consistent with how the
parser treats malformed data today and avoids pre-empting the leniency decision shared by #51, #52
and #14.