#### Brief overview of PR changes/additions
- `createMapper()` raises `mapOpenEvent` again when the profile's map is
already loaded, and repopulates/reselects the mapper's area dropdown on
that path
- The redundant second `map->restore()` that `2a3334a6a` ("Fix: don't
load a map if trying to create a mapper & map is already loaded
(#9415)") was written to skip is still skipped - only the event raise
and the combo box setup move back out of its guard, matching the shape
`Host::createMapper()` has always had
- New `EmbeddedMapperCreationTest` functional test covering both sides
of the branch; the busted suite structurally cannot, since an embedded
mapper and the dockable map widget are mutually exclusive for the life
of a profile
#### Motivation for adding to Mudlet
Every returning user has a saved map, so `createMapper()` and
`Geyser.Mapper{embedded = true}` hit exactly this path, and third-party
mapping scripts that finish setting themselves up on `mapOpenEvent`
silently stopped running.
#### Other info (issues closed, discussion etc)
Found in the 5.0 QA sweep (finding C4), verified on two pristine
profiles: 0 rooms raises the event once, 1 room raised it zero times.
The same guard also swallowed
`updateAreaComboBox()`/`resetAreaComboBoxToPlayerRoomArea()`, which left
the area dropdown reading "Default Area" while the player room was
elsewhere.
Assisted-by: Claude:claude-opus-5
**Test case:** on a profile with a saved map, run
`registerAnonymousEventHandler("mapOpenEvent", function()
echo("\nmapOpenEvent fired\n") end) createMapper(0, 0, 400, 400)` - the
echo appears, and the mapper's area dropdown shows the player's area.
