perf(tags): cache UMI position in DecodedRecord to avoid per-record duplicate find_tag_position scan #334

fgumi_raw_bam::tags::find_tag_position accounts for ~5% of CPU time on fgumi group (4.94% measured on a CODEC 8M-record samply profile, threads=4). The function itself is well-optimized (u16 tag compare, early-exit on missing length sentinels), and the existing single-pass extractors (extract_aux_string_tags, extract_template_aux_tags, filter_template_raw's inline loop) already amortize multi-tag lookups within a single function call.

The remaining cost is structural: the same record's aux data is scanned multiple times across the chain because each step looks up tags independently:

For an 8M-record fgumi group run that's ~3 separate aux-data scans per record on top of the single-pass extractors. RX in particular is scanned twice (once during filter, once during UMI assignment).

Proposed fix. Add umi_offset: u32 and umi_len: u16 to DecodedRecord (or the equivalent intermediate carrier), populated once in the Decode step alongside the GroupKey. Downstream assign_umi_groups_* reads the UMI bytes by slice into the cached offset/len without a second find_tag_position call. Estimated saving: ≈100 samples on fgumi group-like workloads.

Verification approach. Profile-diff target/profiling/fgumi group with samply at 999 Hz before/after on agilent-hs2.mapped.bam (53M records); expect find_tag_position (and its callers in assign_umi_groups_for_indices_impl) to drop by roughly half their current contribution.