Launcher utility subprocesses abort with std::bad_function_call on Linux

NOTE FOR TRIAGE: this is a Minecraft Launcher bug (liblauncher.so), not a game
bug. The game itself runs and exits normally. Please move this to the MCL
project if appropriate, as this portal offered no launcher category.

SHORT DESCRIPTION

Every play session, a burst of 8 to 11 launcher utility subprocesses terminates
abnormally with SIGABRT, each producing a ~17 MB core dump. This has happened
consistently on every session since this launcher was installed, and is still
present on the current launcher build.

Nothing visibly fails: the main launcher process survives, the game runs
normally, and the launcher later exits cleanly with code 0. The only
user-visible symptoms are desktop crash notifications and steadily growing
disk usage under /var/lib/systemd/coredump.

The uncaught exception is:

terminate called after throwing an instance of 'std::bad_function_call'
what(): bad_function_call

This indicates an empty std::function being invoked. The exception propagates
out of liblauncher.so with no handler and reaches std::terminate().

STEPS TO REPRODUCE

1. Launch the official Minecraft Launcher on Linux.

2. Start Minecraft: Java Edition from the launcher.

3. Wait for the launcher window to hide after the game starts.

4. Roughly 12 seconds later, 8-11 utility subprocesses abort. Verify with:
   journalctl -b | grep bad_function_call
   coredumpctl list minecraft-launc

Opening and closing the launcher WITHOUT starting the game does not
reproduce the issue. Launching the game, and the resulting
"Hiding launcher!" transition, appears to be required.

EXPECTED RESULT

Utility subprocesses start normally, or fail gracefully without an uncaught
exception and without generating core dumps.

ACTUAL RESULT

Each spawned utility subprocess immediately aborts on an uncaught
std::bad_function_call and produces a core dump. No user-facing error is shown
and the launcher does not log the failure.

TRIGGER AND CORRELATION

From launcher_log.txt (UTC), example session:

15:23:30.792 client_handler.cpp(875) NotifyBrowserClosing
15:23:30.800 client_handler.cpp(904) NotifyBrowserClosed
15:23:30.801 root_window_manager(339) All windows are gone.
15:23:30.801 main_context.cpp(454) Hiding launcher!
... ~12 seconds ...
15:23:42.469 LauncherAppBrowser.cpp(82) Will launch a Chromium subprocess:
--type=utility --utility-sub-type=patch.mojom.FilePatcher
15:23:42.490 --utility-sub-type=unzip.mojom.Unzipper
15:23:42.578 patch.mojom.FilePatcher
15:23:42.600 unzip.mojom.Unzipper
15:23:42.689 patch.mojom.FilePatcher
15:23:42.737 unzip.mojom.Unzipper
15:23:42.963 patch.mojom.FilePatcher
15:23:43.007 unzip.mojom.Unzipper

Eight spawns, in alternating FilePatcher / Unzipper pairs. Each aborts
immediately. The system journal records exactly eight SIGABRT events with
matching timestamps (PIDs 20961, 20967, 20980, 20988, 21001, 21008, 21021,
21028), all with the same std::bad_function_call message.

This looks like the utility services are invoked with callbacks bound to the
browser context destroyed moments earlier, with a retry loop giving up after
four attempts per service type.

Note: launcher_log.txt is in UTC while the system journal is in CEST (UTC+2).
15:23:42 UTC = 17:23:42 CEST. Same events.

STACK TRACE (identical across all aborted processes)

#2 abort (libc.so.6 + 0x284ac)
#5 __cxa_call_terminate (libstdc++.so.6 + 0xa14e3)
#6 __gxx_personality_v0 (libstdc++.so.6 + 0xb2cb0)
#8 _Unwind_Resume (libgcc_s.so.1 + 0x2314d)
#9 (liblauncher.so + 0x1360a3)
#10 (liblauncher.so + 0x29f2f1)
#11 (liblauncher.so + 0x29f43d)
#12 (liblauncher.so + 0x29e9c2)
#13 (liblauncher.so +