fix(build): keep the index tools free of the Wails application

The v3 migration put application.Get() in backend/events and a
ServiceStartup hook in backend/explore, both of which cmd/indexbuild
reaches. v3's application package is GTK/WebKit bindings on Linux, so
the index-artifact job — a plain golang container with CGO_ENABLED=0,
on the stated grounds that neither command imports the app — stopped
compiling with "undefined: pointer". That job owns the ~205 GB dump
checkpoint, so it is the worst place to learn this.

Both are behind the indexbuild tag now: the one app.Event.Emit lives in
runtime_wails.go, runtime_indexbuild.go answers ErrNoRuntime (what the
app itself returns before Run, so Deliver's callers need no second
path), and explore's ServiceStartup moves to its own tagged file.

TestIndexToolsDoNotImportWails walks `go list -deps -tags indexbuild`
so the claim the workflow makes is checked rather than assumed.

backend/events/runtime_indexbuild.go

@@ -0,0 +1,18 @@
+//go:build indexbuild
+
+package events
+
+// emitRuntime is the index tools' half of the split described in
+// runtime_wails.go: under the indexbuild tag there is no Wails
+// application to emit through, and importing the one that would be
+// there costs cgo and a GTK/WebKit toolchain the index build container
+// deliberately does not have.
+//
+// Returning ErrNoRuntime is the same answer the app gives before Run
+// and after shutdown, so Emit's callers need no second code path: an
+// event emitted by cmd/indexbuild is logged and dropped.  A test that
+// wants to observe one installs a Sink with WithSink, which Deliver
+// consults first and which works under either tag.
+func emitRuntime(_ string, _ ...any) error {
+	return ErrNoRuntime
+}