mavgpud: a yield stops writing a core and reads as a yield (V-491)

llama-server aborts inside its own static teardown on SIGTERM — the
handler calls exit(), stream_session_manager's destructor throws, and the
process dies "signal: aborted (core dumped)". mavgpud sends that signal on
every eviction, so a routine yield wrote a multi-gigabyte core into
systemd-coredump and logged the same line a real crash would.

LimitCORE=0 in the unit stops the disk cost. A yielding flag, set by stop
and cleared by start, makes the log distinguish the two: only an exit we
did not ask for is still reported as an exit.

Not filed upstream. Searched ggml-org/llama.cpp for
"ggml_uncaught_exception" with SIGTERM and for stream_session_manager and
found nothing matching, so the issue still wants writing — by someone with
an account on that tracker, which is why it is not in this commit.

deploy/mavgpud.service

@@ -19,6 +19,10 @@ RestartSec=5
 # llama-server on SIGTERM, so give it longer than stop_grace to do that.
 KillSignal=SIGTERM
 TimeoutStopSec=60
+# llama-server aborts inside its own static teardown on SIGTERM, so every
+# routine yield used to write a multi-gigabyte core into systemd-coredump
+# (Vikunja #491). Yielding is meant to happen several times a day.
+LimitCORE=0
 
 [Install]
 WantedBy=default.target