Fix: drop_throw assumed breakobj unconditionally breaks an object

This looks like an omission from post-merge commit 8bb473b. The code
here is specific to xNetHack, having been added fairly early as part of
the object materials system, and was intended to break non-shatterproof
glass missiles to balance their generally superior damage.

However, this code assumed that breakobj would completely delete the
object, an assumption which is no longer true. This caused a fuzzer
crash when breakobj did NOT delete the object, and gt.thrownobj remained
set to it without being cleared. The fix is to check the return of
breakobj and only return early when the object has in fact been deleted.
Otherwise, fall through to the standard missile-fall handling (which
includes the regular chance of glass ammo, like any ammo, mulching and
vanishing without a message).

Author: copperwater

src/mthrowu.c

@@ -185,8 +185,12 @@ drop_throw(
     /* glass and other fragile objects */
     if (!IS_SOFT(levl[x][y].typ) && breaktest(obj)) {
         breakmsg(obj, cansee(x, y));
-        breakobj(obj, x, y, FALSE, FALSE);
-        return TRUE; /* it's already deleted */
+        if (breakobj(obj, x, y, FALSE, FALSE))
+            /* object was already deleted; return early */
+            return TRUE;
+        /* if breakobj returned 0 (e.g. glass cracked but didn't fully shatter),
+         * don't set broken to FALSE even so. if it did, glass ammo would
+         * weirdly be exempt from mulching. */
     }
     if (broken) {
         delobj(obj);