events get shows null location for guest events (locationInfo not mapped)

[KalebCole]

Problem

After #57 (PR #59) restored events get via /getEventInfo, guest events (events the authenticated user does not host) return location as a nested locationInfo object rather than the flat location/address fields the CLI reads. So partiful events get <guestEventId> succeeds but shows location: null / address: null even when an approximate location exists.

Hosted events are unaffected — they return flat location/address.

Evidence (live API, guest event)

{
  "location": null,
  "locationInfo": {
    "type": "structured",
    "mapsInfo": {
      "name": "Gas Works Park",
      "addressLines": ["2101 N Northlake Way", "Seattle, WA 98103"],
      "approximateLocation": "Seattle, WA"
    },
    "displayAddressLines": ["2101 N Northlake Way", "Seattle, WA"],
    "neighborhood": "Wallingford"
  }
}

Some guest events only expose mapsInfo.approximateLocation (e.g. "Seattle, WA") with empty addressLines — i.e. the host has hidden the exact address from non-hosts. That's a Partiful privacy behavior, not a bug.

Proposed fix

In events get (and +export), when flat location/address are absent, derive display values from locationInfo:

• location ← locationInfo.mapsInfo.name || locationInfo.mapsInfo.approximateLocation
• address ← locationInfo.mapsInfo.addressLines.join(', ') when non-empty
• consider surfacing locationInfo raw as an additive field for scripting

Scope note

Must be consumer-specific, NOT a blanket map:

• +clone must not inherit a vague approximateLocation ("Seattle, WA") as the new event's real location — leave clone reading flat fields only.
• Read-only display consumers (events get, +export, guests header) are the ones that should enrich from locationInfo.

Not a regression

Pre-#57 the endpoint 404'd for all events, so this is strictly better and there is no crash (|| null defaults absorb the missing fields). Tracking as a follow-up enhancement.