Remove clipboard_watcher submodule and migration harness

Author: lijy91

.gitmodules

@@ -14,7 +14,3 @@
 	path = bindings/dart/window_manager
 	url = git@github.com:leanflutter/window_manager.git
 	branch = main
-[submodule "bindings/dart/clipboard_watcher"]
-	path = bindings/dart/clipboard_watcher
-	url = git@github.com:leanflutter/clipboard_watcher.git
-	branch = main

AGENTS.md

@@ -1,13 +1,13 @@
 # libnativeapi workspace
 
-This is the workspace repo (`libnativeapi/nativeapi`, formerly `nativeapi-flutter` and `nativeapi-workspace`) for the [libnativeapi](https://github.com/libnativeapi) project family. Every binding (`bindings/dart/`, `bindings/rust/`, `bindings/csharp/`, `bindings/js/`, `bindings/python/`, `bindings/go/`), the code generator (`tools/codegen/`), the `./codegen` script, the specs and the shared tooling live directly in this repo (the Rust and C# histories were merged in from `nativeapi-rust` and `nativeapi-csharp`); only `core/` and the leanflutter packages under `bindings/dart/` (`tray_manager/`, `screen_retriever/`, `window_manager/`, `clipboard_watcher/`) are git submodules of independent repositories. Work inside a submodule is committed and pushed from that subdirectory; everything else is committed here.
+This is the workspace repo (`libnativeapi/nativeapi`, formerly `nativeapi-flutter` and `nativeapi-workspace`) for the [libnativeapi](https://github.com/libnativeapi) project family. Every binding (`bindings/dart/`, `bindings/rust/`, `bindings/csharp/`, `bindings/js/`, `bindings/python/`, `bindings/go/`), the code generator (`tools/codegen/`), the `./codegen` script, the specs and the shared tooling live directly in this repo (the Rust and C# histories were merged in from `nativeapi-rust` and `nativeapi-csharp`); only `core/` and the leanflutter packages under `bindings/dart/` (`tray_manager/`, `screen_retriever/`, `window_manager/`) are git submodules of independent repositories. Work inside a submodule is committed and pushed from that subdirectory; everything else is committed here.
 
 ## Layout
 
 ```
 core/               # submodule: nativeapi-core — the C++ core library
 bindings/
-├── dart/           # the Dart binding: nativeapi/, cnativeapi/, nativeapi_flutter/; tray_manager/, screen_retriever/, window_manager/, clipboard_watcher/ (submodules of the leanflutter repos of the same names)
+├── dart/           # the Dart binding: nativeapi/, cnativeapi/, nativeapi_flutter/; tray_manager/, screen_retriever/, window_manager/ (submodules of the leanflutter repos of the same names)
 ├── rust/           # the Rust binding: crates/{nativeapi,cnativeapi}
 ├── csharp/         # the C# binding: src/, tests/, NativeAPI.slnx
 ├── js/             # the JS/TS binding: a Node-API addon (src/) + TypeScript (lib/)
@@ -109,7 +109,7 @@ scenarios for *this project's* examples live in [tools/gui/](tools/gui/README.md
 ## Conventions
 
 - `core` tracks `branch = main`. Use `make sync` to fast-forward it; `make status` to see dirty state everywhere; `make bump` to stage its pointer.
-- The leanflutter packages built on nativeapi (`tray_manager`, `window_manager`, `launch_at_startup`, …) live in their own repos under github.com/leanflutter and depend on the published `nativeapi`. Some ride along as submodules under `bindings/dart/<package>` (tracking `main`): `tray_manager`, `screen_retriever`, `window_manager` and `clipboard_watcher` so far. They are not members of the root pub workspace, melos ignores them (add the path to `ignore` in the root `pubspec.yaml`), and CI does not check them out. To try one against local changes, point a `dependency_overrides` entry in that package at `bindings/dart/nativeapi_flutter` (and `nativeapi`, `cnativeapi`) and never commit the override.
+- The leanflutter packages built on nativeapi (`tray_manager`, `window_manager`, `launch_at_startup`, …) live in their own repos under github.com/leanflutter and depend on the published `nativeapi`. Some ride along as submodules under `bindings/dart/<package>` (tracking `main`): `tray_manager`, `screen_retriever` and `window_manager` so far. They are not members of the root pub workspace, melos ignores them (add the path to `ignore` in the root `pubspec.yaml`), and CI does not check them out. To try one against local changes, point a `dependency_overrides` entry in that package at `bindings/dart/nativeapi_flutter` (and `nativeapi`, `cnativeapi`) and never commit the override.
 - Commit workspace submodule pointer updates only when the combination is compatible (a known-good snapshot).
 - Examples live in `examples/<binding>_<name>_example` (`dart_` for plain Dart programs, `flutter_`, `rust_`, `csharp_`, `js_`, `python_`, `go_`), not inside the bindings; a new Dart, Flutter or Rust example must also be listed in the root `pubspec.yaml` / `Cargo.toml`, a C# one in `bindings/csharp/NativeAPI.slnx`, a JS one in the root `package.json`. A Python example is a standalone uv project whose `pyproject.toml` points `nativeapi` at `../../bindings/python` (`uv run main.py` builds the wheel). A Go example is a standalone module whose `go.mod` replaces `github.com/libnativeapi/nativeapi/bindings/go` with `../../bindings/go`. Only the pub.dev package examples (`bindings/dart/*/example`) stay inside their package.
 - CI is one workflow per binding (`dart-ci.yml`, `rust-ci.yml`, `csharp-ci.yml`, `js-ci.yml`, `python-ci.yml`, `go-ci.yml`), each running only for changes under its `bindings/<lang>/` and its examples (`examples/dart_*` and `examples/flutter_*` for Dart, `examples/rust_*`, `examples/csharp_*`, `examples/js_*`, `examples/python_*`, `examples/go_*`). Release tags are per binding: `v*` publishes the Dart packages (`dart-release.yml`), `rust-v*` publishes the crates (`rust-release.yml`), `python-v*` publishes the Python package to PyPI (`python-release.yml`: an sdist carrying core in `cxx_impl/`, and wheels built from it with cibuildwheel; the tag must equal `python-v` + the version in `bindings/python/pyproject.toml`); never push a bare `v*` tag for anything but the Dart packages. Nothing has been published to PyPI yet: the first release needs `nativeapi` set up on PyPI with this workflow and the `pypi` environment as a trusted publisher.

bindings/dart/clipboard_watcher

@@ -41,7 +41,6 @@ melos:
     - "bindings/dart/tray_manager/**"
     - "bindings/dart/screen_retriever/**"
     - "bindings/dart/window_manager/**"
-    - "bindings/dart/clipboard_watcher/**"
     - "**/build/**"
     - "**/.dart_tool/**"
     - "**/.symlinks/**"

pubspec.yaml

@@ -50,7 +50,6 @@ runner) lives in [`.agents/skills/`](../../.agents/skills); read
 | `core/tests/window_shadow_remap_linux_test` (in core) | core hidden-title-bar shadow | Linux (Hyprland; any compositor) | no-input regression, run floating (`hl.window_rule` for its class on Hyprland): a window whose title bar is hidden keeps its content size across hide and show whatever xdg states the compositor sends - Hyprland reports every window tiled and maximized, and GDK takes no resize while they stand, so core must not add its shadow gutter before the compositor has answered. Three timings of hiding the title bar; exact content size once settled, no gutter band and no growth across shows in all of them |
 | `core_window_focus_policy_test.ps1` | core `tests/window_focus_policy_test` | Windows | real clicks on a native child button preserve the anchor window's keyboard focus (set `CORE_FOCUS_TEST_FOREIGN=1` to place the anchor in a separate process) in four combinations of `SetFocusable` and `SetNonActivating`; clicks remain delivered. The executable also checks native styles and mouse-activation responses, `Show`/`Focus`, state shared across wrappers, and restoring focusability. Build in `$REMOTE_SCRATCH/core-build`, or set `CORE_FOCUS_TEST_EXE` to the executable path. Linux runs the same executable without `--clicks`, in a desktop whose window manager honors GTK focus hints (Xvfb + Openbox also works); WSLg does not honor them |
 | `core_tray_icon_events_test_linux.sh` | core `tray_icon_example` (C++) | Linux | the tray icon's menu export and events, driven over D-Bus the way the shell drives a StatusNotifierItem (the input driver may not press the top bar): with the `RightClicked` trigger the menu is exported (`Menu`, its items in `GetLayout`) without `ItemIsMenu`; `WindowId` is an int32, as gnome-shell reads it; the host's dbusmenu events come back as menu events (`opened` / `closed` on the root once each however often they come, `clicked` on an item); from a host other than gnome-shell `Activate` is a click, a second one within the double-click time a double click (a third starts a new pair, two slow ones are two clicks), `ContextMenu` a right click; `SecondaryActivate` and `Scroll` report nothing yet. Not covered: gnome-shell's own `Activate` (a double click) and a real host's menu, which only real clicks in the top bar show — checked by hand on GNOME 46 and in KDE Plasma 6 |
-| `flutter_clipboard_watcher_test.py` | `clipboard_watcher` submodule example | macOS | no synthetic input: nativeapi and Flutter clipboard interoperability, text/HTML roundtrip, native + legacy subscriptions, idempotent start/stop and restart, listener removal and stop during dispatch, clear notifications; the core wrapper snapshots and restores every original pasteboard format even on failure |
 | `flutter_launch_at_startup_test.py` | `launch_at_startup`'s own example, in a leanflutter checkout (`$LEANFLUTTER_DIR`, default `~/Projects/leanflutter`; see `common.py`) | macOS | the 0.5.x compatible API on nativeapi: Enable registers an `SMAppService` login item, `isEnabled` reads it back, Disable removes it, and `setup(args:)` neither throws nor leaves an entry behind. Always leaves the login item off, including on a failure. Written but not yet run — the display was asleep; the same sequence was verified headlessly instead |
 | `flutter_detachable_window_and_browser_tabs_demo.py` / `.ps1` | both Flutter examples | macOS / Windows | the demo video scenarios; also the only coverage of `browser_tabs_example` (reorder, tear off, merge, move by the strip; its log ends with the preserved page state, no PASS/FAIL checks) |
 | `flutter_floating_toolbar_demo.py` / `.ps1` | `floating_toolbar_example` | macOS / Windows | the floating toolbar demo video: the pill drives the main window (colours, Stamp), follows it when it is dragged by the title bar and resized from its corner, stays behind when detached and snaps back when attached, is hidden and shown again; ends on the counter and the log. `DEMO_DRY_RUN=1` on the Windows host plays it without recording; without `--record` the macOS script does the same |