Let a typed employee name find the employee

Reported from the floor: somebody types the employee's whole name into the
notification or recognition picker and presses Enter instead of clicking the
suggestion, and the entry does not pull from the employee database.

Two causes, one symptom.

The search matched the WHOLE query against first name or last name, so "Dana
Reyes" found nobody - no single column holds that string. Typing a full name is
what a person does before pressing Enter, and it was the one thing guaranteed to
return an empty list. A multi-word query is now treated as a full name: every
word must appear somewhere in the name, in either column, so "Reyes Dana" works
too, and "Dana Reyes" does not also return Sam Reyes. A single word still
searches broadly, and an SSO still resolves. Both directory backends changed,
the self-hosted tables and the external HR database.

With no suggestion to click, the form then turned the typed text into
`NAME:<text>` - a label linked to nothing. On screen that chip is identical to a
real selection; the difference only shows up later as no photo, no directory
link, and a recognition the person it is about cannot be found by. Both pickers
(the notifications form and the shared EmployeeSearch component) now look a
typed name up before deciding it is free text, through one helper.

An exact full-name match wins over a longer partial one, because somebody typing
"Dana Reyes" means that person and not "Dana Reyes-Smith". A genuinely ambiguous
name is NOT guessed at - the candidates are shown and the operator picks, which
is exactly when picking wrong matters most. A directory that cannot be reached
reports failure rather than silently producing a label.

Eleven tests. The search rules verified by planting the single-term query back.

One note for whoever reads the spec: the failure-branch test uses a thenable
that rejects rather than a mock returning a rejected promise. The runner
collects such a promise as an unhandled error even when the code under test
catches it, and fails the very test that proves the catch works.

Scope: product

shopdb/core/models/asset.py

@@ -256,6 +256,24 @@ class Asset(BaseModel, SoftDeleteMixin, AuditMixin):
         elif hasattr(self, 'measuringtool') and self.measuringtool:
             result['pluginid'] = self.measuringtool.measuringtoolid
 
+        # What this asset OWNS, before any inheritance is merged in below.
+        #
+        # The merge is right for a reader: a detail page, a list and the map all
+        # want the resolved location, whoever it came from. It is wrong for a
+        # FORM, which reads the same payload and cannot tell an owned value
+        # from a derived one - so the PC form pre-selected an inherited
+        # location, the operator saved something else entirely, and the
+        # inherited value was written back as the record's own. The asset then
+        # stopped following its parent, silently, on an edit that never touched
+        # location.
+        #
+        # Always emitted, even when nothing is inherited, so a client can bind
+        # to these without checking whether the merge happened.
+        result['ownlocationid'] = self.locationid
+        result['ownmapx'] = self.mapx
+        result['ownmapy'] = self.mapy
+        result['ownlevelid'] = self.levelid
+
         # Include inherited location if this asset has no location data
         if include_inherited_location:
             inherited = self.get_inherited_location()