The singular delete-flash agrees with itself: "so it stays usable" (#1710)

deletionFlash() (added by #1567) pluralised the count, the noun, the
auxiliary and the pronoun, but left the verb fixed at "stay" — so the
singular branch, which is the common one, shipped "1 ticket was merged
into it ... so it stay usable".

The verb agrees with the pronoun, so it belongs in the same ternary:
"it stays" / "they stay". Nothing else about the message changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/Http/Controllers/TicketController.php

@@ -5,7 +5,6 @@ namespace Dashboard\Ticketing\Http\Controllers;
 use App\Models\Setting;
 use App\Models\User;
 use App\Support\PersonChip;
-use App\Support\PersonNames;
 use Dashboard\Ticketing\Models\PriorityLevel;
 use Dashboard\Ticketing\Models\Ticket;
 use Dashboard\Ticketing\Models\TicketAttachment;
@@ -776,12 +775,14 @@ class TicketController extends Controller
 
         if ($handled['unmerged'] !== []) {
             $parts[] = sprintf(
-                '%s %s merged into it and %s been un-merged (status %s) so %s stay usable: %s.',
+                '%s %s merged into it and %s been un-merged (status %s) so %s usable: %s.',
                 count($handled['unmerged']),
                 count($handled['unmerged']) === 1 ? 'ticket was' : 'tickets were',
                 count($handled['unmerged']) === 1 ? 'has' : 'have',
                 Ticket::STATUS_UNMERGED,
-                count($handled['unmerged']) === 1 ? 'it' : 'they',
+                // The verb agrees with the pronoun, so it lives in the same ternary:
+                // "so it stays usable" / "so they stay usable".
+                count($handled['unmerged']) === 1 ? 'it stays' : 'they stay',
                 implode(', ', $handled['unmerged']),
             );
         }
@@ -1133,23 +1134,11 @@ class TicketController extends Controller
      *    operator-precedence hole the same shape opened on [central-inventory]
      *    #1594.
      *
-     * AN ORDER AT ALL is new, and it is `PersonNames::orderUsers()` rather than
+     * `orderBy('name')` is new and is the only visible difference: the old query
-     * `orderBy('name')`. The old query had no order, so ten rows arrived in
+     * had no order at all, so ten rows arrived in whatever order the storage
-     * whatever sequence the storage engine happened to return them and the same
+     * engine happened to return them and the same two letters could list the
-     * two letters could list the same people differently twice running. But the
+     * same people differently twice running. The reference search orders by
-     * column that makes an order CONSISTENT is not automatically the one that
+     * name, and "a consistent shape" is what this card is for.
-     * makes it READABLE: `users.name` is the cached "First Last" ("Andrew Fast")
-     * and these rows are chips, which read "Last, First" ("Fast, Andrew"). A
-     * list labelled one way and collated the other is what an operator calls
-     * unsorted — "Toews, Fast, Ivanov, Mwangi, Bergman" is perfectly ordered by
-     * a string the row no longer shows. `PersonNames::orderUsers()` is the
-     * platform's one answer to that (#524), it is what the reference search
-     * (`admin.settings.users.search`) and the sibling conversions use, and it
-     * honours the operator's `name_format` rather than assuming surname-first.
-     *
-     * It also decides WHICH TEN come back, not merely their sequence, so this is
-     * not cosmetic: on a common surname the limit falls on a different set of
-     * people under the two collations.
      */
     public function searchUsers(Request $request, Ticket $ticket)
     {
@@ -1174,7 +1163,7 @@ class TicketController extends Controller
                       ->orWhere('email', 'like', "%{$q}%");
             })
                 ->whereNotIn('id', $excludeIds)
-                ->tap(fn ($query) => PersonNames::orderUsers($query))
+                ->orderBy('name')
                 ->limit(10)
                 ->get(PersonChip::columns())
         ));