refid: set the registry's clock so period resets can be tested #309

Current Limitation

Registry.Generate reads the time from time.Now().UTC(). The date segments and the date placeholders of a scope key ({yyyy}, {yyyyMM}, {yyyyMMdd}) all derive from that one value, and a test can't set it. So the behaviour that makes a counter restart each year, month or day isn't covered by a test: TestScopeKey_DailyReset notes that it validates the reset "indirectly", because it can't cross a day boundary.

Two related cases have no test either:

• a format that holds more than one date segment with different layouts, e.g. 2006, /, 01, then a sequence (every existing test uses a single 20060102 layout);
• the scope key a period placeholder produces at a period boundary, for example the last second of a year and the first second of the next.

Suggested Improvement

• A clock option on the registry:

  // WithClock sets the time Generate reads. The default is time.Now.
  func WithClock(now func() time.Time) RegistryOption

  Generate calls it once per ID and converts the result to UTC, so every segment of one ID still shares one value.

• Generic tests that use the option:

  • a sequence scoped with {yyyy}, {yyyyMM} or {yyyyMMdd} restarts at 1 when the clock crosses that boundary and continues within it;
  • a counter scoped without a date placeholder keeps counting across the boundary;
  • a format with two date segments of different layouts renders both from the same clock value, including across a boundary;
  • a clock in a non-UTC zone is rendered in UTC.

• TestScopeKey_DailyReset asserts the restart directly.

Additive: existing callers keep the current behaviour.

Version

refid/v0.3.0; main at b47ceae (#307)

Additional Context

A host uses period-scoped counters for numbers that restart every year. A clock option lets the library's own tests prove the restart for every placeholder, so a host doesn't have to repeat that check against its own formats.