computeAffectedVersions narrows coarse window after SortEvents lexicographic fallback

## Summary

In `go/internal/database/datastore/affected_versions.go`, `computeAffectedVersions` calls `osvutil.SortEvents` and discards the error:

```go
_ = osvutil.SortEvents(eHelper, events)
```

When any event version fails `Parse`/`Compare`, `SortEvents` re-sorts lexicographically (documented as arbitrary/stable) and **returns that error** to signal the order is not semantic. The caller still derives `coarse_min` / `coarse_max` from positional assumptions that only hold under a semantic sort (first `introduced`, last event).

Those coarse bounds become hard Datastore inequality filters in `buildVersionMatcher`, so a row excluded by a wrongly-narrowed window is never returned to the semantic matcher.

## Worked example (Packagist)

Events: `introduced 1.0`, `fixed 9.0`, `introduced 20.0`, `fixed 30.0`, `introduced 1.0#bad` (Packagist rejects `#`).

Lexicographic fallback order ends with `fixed 9.0`, so today's code emits `coarse_max = coarse(9.0)`. Version `25.0` is semantically in-range (`20.0`–`30.0`) but fails the `coarse_max >= coarse(25.0)` pre-filter.

## Expected

On `SortEvents` error, leave `coarse_min`/`coarse_max` at the unbounded defaults (`00:000…` / `99:999…`), matching the Python `_get_coarse_min_max` `ValueError` path that resets to `MIN`/`MAX`.

## Note

This is a correctness / false-negative matching bug in the Go datastore index path (live importer/worker), not a security advisory request. Happy to send a small patch + unit test once this is assigned per CONTRIBUTING.

Start in go/internal/database/datastore/affected_versions.go at computeAffectedVersions and trace its call to osvutil.SortEvents, then inspect how buildVersionMatcher uses coarse_min and coarse_max. Add a unit test for the documented Packagist-style fallback case; done means a SortEvents error leaves both coarse bounds unbounded so the semantic matcher can find the affected version.

Written by the indexing model from the issue text.