fix(en-tn): verbalize plural time unit abbreviations (mins/hrs/secs)

[JMak-Security]

Summary

en/data/measure/unit.tsv maps the singular time abbreviations min, sec, hr to their spoken forms, but not the plural written forms mins, hrs, secs. Since measure normalization only fires when the written token is recognized as a unit, the plural forms pass through unverbalized:

'5 mins'     -> 'five mins'          # should be 'five minutes'
'2-3 mins'   -> 'two - three mins'   # should be 'two to three minutes'

The range case is the more visible failure: the measure range rule can't fire either, so the hyphen from '2-3' is left in the output -- for TTS this renders as silence/a pause.

Root cause

Confirmed directly against unit.tsv at HEAD (acacc21b): lbs -> pound (L45) and sec/min/hr (L128-130) exist, but no plural written forms for the time units.

Fix

No grammar change is needed. MeasureFst already derives the spoken plural from the singular value:

graph_unit_plural = convert_space(graph_unit @ SINGULAR_TO_PLURAL)  # taggers/measure.py L74

So a plural written key only needs a row mapping to the existing singular spoken form -- the same pattern already used for lbs -> pound. This adds:

mins	minute
hrs	hour
secs	second

grouped with their singular counterparts (sec/min/hr) in the file.

This PR is scoped to the confirmed bug only. The issue also proposes a separate extensibility mechanism (an extra_unit_file hook to let callers append custom units without regenerating the shipped FAR cache) -- that's a larger design question spanning Normalizer construction, MeasureFst, and FAR cache invalidation, and is left for separate discussion/PR.

Testing

I couldn't get a local pynini/nemo-text-processing install running in my environment (cdifflib, a transitive dependency, needs a C++ build toolchain I don't have here), so I verified this the way available to me:

• Confirmed via the GitHub contents API that unit.tsv at the exact commit HEAD currently points to lacks mins/hrs/secs, matching the bug report precisely.
• Read taggers/measure.py directly and traced the graph_unit_plural = convert_space(graph_unit @ SINGULAR_TO_PLURAL) composition myself to independently confirm the plural-derivation mechanism the fix relies on, rather than taking the issue's claim at face value.
• Confirmed the exact same pattern (plural written key -> singular spoken value) is already an established, working precedent via the existing lbs -> pound row.
• The issue reporter independently verified this exact three-line change locally against nemo-text-processing==1.2.0 / pynini 2.1.6.post1, with before/after output for '5 mins', '2-3 mins', '2-3 hrs', '30-45 secs', plus regression checks ('1 min' unaffected, '2013-2016' unaffected).

Fixes #477

[dk-dineshkannaa]

This fix works for mins/hrs/secs, but there are many similar cases — plural abbreviations of units already in unit.tsv, e.g.:

'10 kgs' -> 'ten kgs' (kg is a key, kgs is not)
'25 yrs' -> 'twenty five yrs' (yr is a key)
'6 wks' -> 'six wks' (wk is a key)
'18 mos' -> 'eighteen mos' (mo is a key)

Is there a reason plural written keys are generally excluded ?

[JMak-Security]

@dk-dineshkannaa, thank you, I've confirmed all four against unit.tsv and pushed a follow-up commit adding kgs, wks, mos, yrs.
Scoped it to these four specifically rather than sweeping the whole file: kgs mirrors the lbs -> pound row that already exists (mass units commonly get a colloquial 's' plural despite SI style guides discouraging it), and wks/mos/yrs are the same casual time-count family as the mins/hrs/secs this PR already added.
I'd hold off on mechanically adding 's' to the rest of the file (km, mm, GB, kW, etc.) though - those are SI/technical symbols that aren't commonly written with a plural 's' in practice (nobody writes "5 kms" or "10 GBs" the way they'd write "5 kgs" or "10 yrs"), so blanket-adding them would introduce a lot of entries that don't reflect real usage. If you know of other specific abbreviations in the same "commonly-written-with-s" category I missed, happy to add those too - just didn't want to guess at the boundary without something concrete to verify against, the way your four examples gave me.