Document buildings and levels where the old single-map model was still taught

The 0.11.0 release changed what a map position means and six documents still
described the model it replaced. Each of these could have caused a real mistake
rather than being merely out of date:

- IMPORT-API mapped legacy mapleft/maptop to mapx/mapy with no mention of the
  level, so a scripted import - including the classic-ASP one still to run
  against production - would have produced markers the map shows as "level
  unknown". It now maps levelid too and says how to resolve the default level.
- API-REFERENCE enumerates the unauthenticated surface in full, because that is
  what a deploy reviewer reads, and the three public /api/maplevels reads were
  missing from it. Also records why the write split is asymmetric: repositioning
  needs assets.edit, creating a level needs admin, since a level's dimensions are
  the coordinate space every marker on it is expressed in.
- CONFIG still presented the four map_* settings as live, telling the reader to
  re-upload a blueprint in a settings page that no longer drives the map. They
  are marked superseded and kept for downgrade.
- UPGRADE gained a 0.11.0 section: nothing moves on screen, and replacing a
  blueprint with one of different dimensions moves every marker on that level, so
  recalibrate from landmarks rather than editing width and height.
- PLUGIN-HOOKS now states that a map overlay keys on assetid and must not return
  coordinates or a level - a second copy of a position is one that can disagree.

Adds FLOOR-MAP.md, the operator's page: loading a plan, placing markers, and
what to do when the plan changes, with the reasoning left in ADR-017. START-HERE
routes to it from the new-site path, and specifically as the page to read BEFORE
a floor plan changes.

docs/IMPORT-API.md

@@ -190,12 +190,28 @@ Common `machines` columns -> core Asset fields (same for every target plugin):
 | `serialnumber` | `serialnumber` | |
 | `machinestatusid` | `statusid` | remap via `machinestatus` -> asset statuses |
 | `businessunitid` | `businessunitid` | remap via imported business units |
-| `mapleft` | `mapx` | |
-| `maptop` | `mapy` | |
+| `mapleft` | `mapx` | pixels of a LEVEL; send `levelid` with it |
+| `maptop` | `mapy` | as above |
+| n/a | `levelid` | which floor plan the coordinates belong to (ADR-017) |
 | `machinenotes` | `notes` | |
 | `dateadded` | `createddate` | import mode only |
 | `lastupdated` | `modifieddate` | import mode only |
 
+**A position needs its level.** `mapx`/`mapy` are absolute pixels in the native
+coordinate space of ONE level (ADR-017), so an import that sends coordinates
+without `levelid` produces markers the map renders as "level unknown" rather than
+drawing them on the default level. A legacy source that predates levels has one
+floor plan, so the right value is that site's default level:
+
+```bash
+curl -s http://server/api/maplevels | python -c "import json,sys; print(json.load(sys.stdin)['data']['defaultlevelid'])"
+```
+
+Send that `levelid` on every row carrying coordinates. If an import already ran
+without it, the levels migration's backfill is not retroactive - assign the rows
+with `POST /api/mappositions/positions`, which requires `levelid` per row for
+exactly this reason.
+
 Per-plugin extension fields:
 
 - **computers** (`POST /api/computers`): `hostname` <- `machines.hostname`,