fix(api,panel): refuse file operations on a server without a world volume (#58)

Live: the files page against a server whose world claim does not exist (never
started, or reaped) created a Job whose Pod stayed Pending on
FailedScheduling (persistentvolumeclaim not found) until the executor's 90s
wait expired — a 90s spinner answered by a misleading 504 files_timeout, for
a request that is knowably impossible. Backup and restore have refused this
shape with 409 no_world_volume since the #42 round; the file routes now run
the same gate before any Job is created, and the panel maps the code to a
localized message (it previously fell back to the English server text).

internal/api/handlers_files.go

@@ -210,6 +210,19 @@ func (a *API) authorizeFileOp(w http.ResponseWriter, r *http.Request) (string, b
 		return "", false
 	}
 
+	// World-volume gate, matching the backup/restore faces: the Job mounts the
+	// world PVC by claim name, so a server that has never started (or was already
+	// reaped) has no claim to mount and its Pod sits Pending until the executor's
+	// wait expires — a knowably impossible request answered by a 90s hang and a
+	// misleading 504. Refuse up front with the same specific 409.
+	if exists, err := a.Cluster.WorldVolumeExists(r.Context(), name); err != nil {
+		writeError(w, r, err)
+		return "", false
+	} else if !exists {
+		writeError(w, r, errNoWorldVolume())
+		return "", false
+	}
+
 	// Files is optional: when unwired the endpoints report 503 rather than
 	// panicking, so the authorization boundary above is exercised even before the
 	// file-Job executor is wired (see FileEditor).