fix: store multiple postal codes as array, not last-write-wins scalar

[tomayac]

Fixes #89.

Problem

_alternateNames[geoNameId]["post"] was a scalar, so cities with multiple ZIP codes in alternateNames.txt would silently clobber all but the last entry. Paris, TX (geoNameId 4717560) has three ZIP codes — 75460, 75461, 75462 — but only 75462 was returned because it happened to be last in the dump.

Fix

In _parseGeoNamesAlternateNamesCsv: when isoLanguage === 'post', accumulate entries into an array instead of overwriting:

if (isoLanguage === 'post') {
  if (!Array.isArray(that._alternateNames[geoNameId]['post'])) {
    that._alternateNames[geoNameId]['post'] = [];
  }
  that._alternateNames[geoNameId]['post'].push(entry);
} else {
  that._alternateNames[geoNameId][isoLanguage] = entry;
}

In _lookUp: the alternateName.post field is now an array of all ZIP codes, sorted alphabetically for a stable ordering. All ZIP codes are accessible to callers via alternateName.post[].

Notes on a true centroid approach

alternateNames.txt does not carry per-ZIP lat/lon centroids, so it isn't possible to pick the nearest ZIP to the query point using only data already loaded. A future enhancement could integrate GeoNames' postalCodes.txt (which does include lat/lon per ZIP) to implement genuine nearest-centroid selection. For now, exposing the full array is the honest and correct fix — callers get all ZIP codes rather than an arbitrary one.

Backwards compatibility

alternateName.post changes from a {altName, ...} object to an array of such objects for cities with multiple ZIP codes. Cities with a single ZIP code will now also have an array of length 1 for consistency. Callers reading alternateName.post.altName will need to update to alternateName.post[0].altName (or whichever index they need).