macos: pixel attachments, live theming, and a signed app

The AppKit shell now draws what the core renders, follows the theme without a
relaunch, and builds into something you can hand to someone.

- Pixel attachments. Surface.images was dropped on the floor here, so a PDF
  pane showed nothing at all: native_images is now set, pardes_image_s carries
  the geometry the core already clipped, and PardesView keeps one CGImage per
  (serial, page, revision) so scrolling costs a draw and not a decode. Image
  panes get real pixels instead of the petscii fallback.

- Themes take hold live. pardes_tick never advanced the chrome animation, so
  every tagline kept the previous theme's colours until the next launch and
  the 16 ms re-pump spun for the rest of the session. pardes_theme_bg retires
  the hand-agreed #121212 and drives the window background and the titlebar
  appearance; a theme with no background of its own now gets a transparent
  window over an NSVisualEffectView.

- The cell snaps to whole DEVICE pixels rather than whole points. Monaco
  advances 8.4014pt at 14, so ceiling to 9 spaced every column 7.1% wider than
  the face was drawn for.

- The dial is one notch per 10 degrees instead of 20, and a release keeps
  turning in proportion to how hard it was thrown -- ramping up from zero at
  the floor, so a slow twist coasts not a little but not at all.

- A file dropped on the grid is a click plus Look, so it opens beside the pane
  it was dropped on. No drop concept was added to the core.

- The titlebar follows the focused pane: proxy icon, filename, and the dirty
  dot. File.saved_revision is the watermark that last one needed.

- Config (SPC f c) prints the resolved startup config path.

- build.zig assembles, signs and packages the bundle itself; build-app.sh is
  gone. -Dmacos-identity= takes a Developer ID, macos-dmg makes the image, and
  the icon is Glenda.

1 files changed, 37 insertions, 0 deletions

diff --git a/test/macos-snapshots/drop.snap b/test/macos-snapshots/drop.snap
new file mode 100644
index 00000000..f427fe2a
--- /dev/null
+++ b/test/macos-snapshots/drop.snap
@@ -0,0 +1,37 @@
+# A file dropped ON the grid opens beside the pane it was dropped on.
+#
+# Finder and the Dock already reach the app through application(_:open:), but
+# that path cannot say WHERE — it opens next to whichever pane happened to have
+# focus. A drop knows where the hand was, and in acme that is the whole
+# difference: `Look` places the document relative to the pane it runs in.
+#
+# So a drop is defined as a CLICK followed by `Look`, and nothing more. The
+# click focuses the pane under the pointer exactly as a left click there would,
+# then the ordinary builtin runs in it. There is no drop concept in the core
+# and none was added — everything here the hand could have done itself.
+#
+# `drop` drives PardesView.drop, one call below performDragOperation, because
+# NSDraggingInfo is a protocol with no public conformer: a test that had to
+# build one would be testing its own stub. See the trackpad scripts for the
+# same reasoning about NSTouch and pressure stages.
+start 30 100
+wait 8000 $
+stable 700 20000
+text printf 'first file\n' > one.txt; printf 'second file\n' > two.txt
+key enter
+wait 8000 $
+stable 700 20000
+snap booted
+# Dropped on the shell: one.txt opens as a document beside it. Absolute,
+# because the core resolves a relative Look against the PANE's directory —
+# the same absolute path the AppKit side builds out of an NSURL.
+drop /private/tmp/pardes-macos-e2e/drop/cwd/one.txt 10 6
+stable 700 15000
+snap dropped_on_shell
+# ...and now the placement is the assertion. Dropping the SECOND file inside
+# the pane the first one opened puts it next to that pane, not next to the
+# shell — which is only true because the click went where the pointer was.
+drop /private/tmp/pardes-macos-e2e/drop/cwd/two.txt 10 20
+stable 700 15000
+snap dropped_on_document
+draw drop