docs: read a materialized view's table and definition as properties

`view.table()` and `view.definition()` raise TypeError on a synchronous
view; both are properties. An async view reads its definition with
`await view.definition()`.

docs/web/feature-engineering/materialized-views.mdx

@@ -106,10 +106,11 @@ another view is refreshed by refreshing each in dependency order.
 
 ## Working with the view {#working-with-the-view}
 
-`view.table()` returns the underlying table for querying, indexing, or search.
-`view.definition()` returns the recorded query — the select list, predicate, and
+`view.table` is the underlying table, for querying, indexing, or search.
+`view.definition` is the recorded query — the select list, predicate, and
 limit — which is how you check what a view actually contains without inferring
-it from the rows.
+it from the rows. Both are properties; on an async view, the definition is read
+with `await view.definition()`.
 
 An existing view is reopened with `db.open_materialized_view(name)`.
 

docs/web/management/materialized-view.mdx

@@ -76,10 +76,11 @@ That also means dropping one removes stored rows -- unlike dropping a
 
 ## Working with the view {#working}
 
-`view.table()` returns the underlying table, for querying, indexing, or search.
-`view.definition()` returns the recorded query -- select list, predicate, limit
+`view.table` is the underlying table, for querying, indexing, or search.
+`view.definition` is the recorded query -- select list, predicate, limit
 -- which is how you check what a view contains without inferring it from the
-rows.
+rows. Both are properties; on an async view, the definition is read with
+`await view.definition()`.
 
 ## Against a deployment {#deployment}