Resolve an asset type by name, and send a map position with its level

Wave 5, the asset forms. Both defects are the same mistake in different
clothes: a form deciding something it should have been told.

Four forms carried a hardcoded asset-type id - const COMPUTER_ASSETTYPEID = 2,
and the same for machines, printers and network devices - to tell
CustomFieldsInputs which type's fields to render. Those ids come from seed
order. On the instance they were written against, computer was 2; on a freshly
seeded database computer is 1 and 2 is network_device. So the PC form asked for
another type's custom fields, rendered them, and dropped everything typed into
them behind a success toast, because the values were keyed to a type the record
does not have. Verified in a browser against a correctly built dist: the form
now requests assettypeid=1 on an instance where computer is 1.

The name is the stable thing - assettype is a fixed vocabulary and the API
already publishes the mapping - so composables/assetTypeIds.js resolves it once
per page load. A failed load leaves it undefined, which renders no custom-field
panel: a missing panel is honest, a guessed id is what this replaces.

Three of the five forms that emit a map position sent mapx and mapy without
levelid. ADR-017 is explicit that a position without its level cannot be drawn
on the right floor plan, so a picked pin saved a null level and rendered
nowhere - while the form displayed "Position: x, y" back, because it kept the
value it had never sent.

The ADR-017 gate should have caught that and did not: it globbed '*.py' only,
so it policed what the server emits and never what the browser sends. It now
covers .vue and .js too, and accepts both quoting styles. Verified by planting:
drop levelid from PCForm again and the gate names that exact line.

Five composable tests, including a fixture with a DIFFERENT seed order - the
case the constants got wrong.

Still open from this area, and deliberately not in this commit: the PC form
writes an INHERITED location back as the record's own. Fixing it needs the API
to distinguish an owned locationid from a derived one, which is a contract
change rather than a form fix.

Scope: product

scripts/check-naming-and-style.sh

@@ -191,11 +191,19 @@ while IFS= read -r hit; do
     [ -z "$hit" ] && continue
     file=${hit%%:*}
     line=${hit#*:}; line=${line%%:*}
-    if ! sed -n "${line},$((line + 8))p" "$file" | grep -q "'levelid'"; then
+    # Python writes 'levelid', Vue writes levelid: - accept either, so the
+    # check covers the payloads a browser sends as well as the ones the server
+    # emits. It was Python-only, which is how three asset forms shipped a
+    # position with no level.
+    if ! sed -n "${line},$((line + 8))p" "$file" | grep -qE "'levelid'|levelid:"; then
         MISSING_LEVEL="$MISSING_LEVEL$file:$line"$'\n'
     fi
 done <<EOF
 $(grep -rn "'mapx':" --include='*.py' shopdb/ plugins/ scripts/ 2>/dev/null | grep -v '/tests\?/' || true)
+$(grep -rn "mapx: " --include='*.vue' --include='*.js' \
+    frontend/src plugins/*/frontend 2>/dev/null \
+    | grep -v '.plugins-staged' | grep -v '\.spec\.js' \
+    | grep -vE "mapx: (null|0)," || true)
 EOF
 if [ -n "$MISSING_LEVEL" ]; then
     echo "FAIL: these emit 'mapx' with no 'levelid' beside it - a position with no"