vision: scope the note, settle the contract, wait for the prune

Saving a description writes recall corpus. writeNote embeds it under
media:image:<id>, a source no enrollment owns, and the method sits at
AuthRead, so any enrolled module could put a small VLM's guess into what
Maven knows and have it come back in a later turn as something she
believes. The describing half stays a read; save_note is now held to the
same source-scope rule WriteFact is, and the stored text carries a
marker saying it came off a picture.

Three doc comments said the method exists only when vision is enabled
and the code says otherwise. The code is right, and storing without
describing is the state this box is in, so the comments were corrected
rather than the behaviour. A request carrying both data and id used to
take the id branch and drop the bytes without a word; it is refused.

A media dir that cannot be created and a vision endpoint that is a typo
were logged at wiring time and the capability just stayed off, which is
the hardest kind of misconfiguration to notice. Both fail at startup.
runPrune was the one loop started with a bare go and not in the daemon's
WaitGroup, so shutdown did not wait for a prune that was deleting files.

Found in review of #72.

internal/ipc/server.go

@@ -455,10 +455,12 @@ type Server struct {
 	SwapModelFn   SwapModelFunc
 	ModelStatusFn ModelStatusFunc
 
-	// DescribeImageFn — looks at one image (Vikunja #252). Set by the daemon only
-	// when a media store is configured AND vision is enabled with a local
-	// endpoint; nil ⇒ MethodDescribeImage answers ErrUnknownMethod, so a surface
-	// cannot make Maven accept a photo by merely sending one.
+	// DescribeImageFn — looks at one image (Vikunja #252). Set by the daemon
+	// whenever a media store is configured. Vision being off does not clear it:
+	// the image is stored and the reply says she cannot read it yet, which is
+	// re-runnable by id later. nil ⇒ no media block ⇒ MethodDescribeImage
+	// answers ErrUnknownMethod, so a surface cannot make Maven accept a photo
+	// by merely sending one.
 	//
 	// It bypasses CoreAPI for the same reason IngestMailFn does: it needs a blob
 	// store and a vision server, neither of which is a store operation, and no