v1.0.9

fix: leak fsnotify group on exit to avoid mark destroy race

This platform's fsnotify_destroy_group() lacks
fsnotify_wait_marks_destroyed().  Every previous attempt to fix the
crash in fsnotify_mark_destroy_workfn failed:

  v1.0.5: fsnotify_put_group — workfn races with group free
  v1.0.6: fsnotify_destroy_group + flush_workqueue(after) — flush too late
  v1.0.7: flush_workqueue(before) + fsnotify_destroy_group — delayed work
          not flushed by flush_workqueue
  v1.0.8: fsnotify_put_mark + fsnotify_destroy_group — same delayed work race

Root cause: mark destruction is queued via queue_delayed_work() with
FSNOTIFY_REAPER_DELAY.  flush_workqueue() cannot flush delayed works
whose timer hasn't expired, and the internal reaper_work struct is
inaccessible from modules.

Fix: do not destroy marks or the group at all.  Instead:
- Zero the mark mask to prevent event dispatch to our handler
- Set group->shutdown = true (checked before group->ops dereference)
- Leak ~1 KB of memory (group + mark + inode/path refs)

Since no mark refcount reaches zero, the delayed reaper never fires
for our mark, completely eliminating the race.

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