feat: return a cleanup job from drop_view

Dropping a view unbinds its name and leaves the definition dataset to a cleanup
job, so the two are separate events a caller may want to wait on.
`drop_view_async` returns the job, the same shape `drop_materialized_view_async`
and `drop_function_async` already use: a 202 carries the job id, and a 200 --
nothing bound to the name -- yields an already-finished job.

`drop_view` waits on that job before returning, so a caller that does not want
to think about cleanup gets the stronger guarantee: when it returns, the
definition really is deleted. That differs from `drop_materialized_view` and
`drop_function`, which return as soon as the name is unbound; the view API is
the newer one and this is the semantic worth having.

nodejs/src/connection.rs

@@ -427,7 +427,8 @@ impl Connection {
         ViewDescription::from_inner(view)
     }
 
-    /// Drop a view. The tables it reads are untouched.
+    /// Drop a view and wait for its definition to be deleted. The tables it
+    /// reads are untouched.
     #[napi(catch_unwind)]
     pub async fn drop_view(
         &self,
@@ -441,6 +442,22 @@ impl Connection {
             .default_error()
     }
 
+    /// Start dropping a view and return the job deleting its definition.
+    #[napi(catch_unwind)]
+    pub async fn drop_view_async(
+        &self,
+        name: String,
+        namespace_path: Option<Vec<String>>,
+    ) -> napi::Result<crate::job::Job> {
+        let ns = namespace_path.unwrap_or_default();
+        let job = self
+            .get_inner()?
+            .drop_view_async(&name, &ns)
+            .await
+            .default_error()?;
+        Ok(crate::job::Job::new(job))
+    }
+
     /// The names of the views in one namespace.
     #[napi(catch_unwind)]
     pub async fn list_views(