docs: clean up prose flagged by the shared Vale rules (#4596)

The existing docs have 254 findings from our shared Vale rules.
Contributors would otherwise inherit these when editing the same lines.

Clean up the prose across 80 pages: correct product names and a repeated
word, simplify a few phrases, and replace dashes with punctuation that
fits each sentence. The pinned Vale scan now reports zero findings, with
no suppressions.

docs/web/sql/dql/aggregation.mdx

@@ -32,7 +32,7 @@ SELECT category, source, count(*) FROM documents GROUP BY category, source
 
 ## Aggregate without grouping {#whole-table}
 
-Omitting `GROUP BY` aggregates the whole table into one row -- the usual way to
+Omitting `GROUP BY` aggregates the whole table into one row, which is the usual way to
 ask how big something is:
 
 ```sql

docs/web/sql/dql/explain.mdx

@@ -1,7 +1,7 @@
 ---
 title: "Explain"
 sidebarTitle: "Explain"
-description: "EXPLAIN, EXPLAIN ANALYZE and EXPLAIN VERBOSE — reading and measuring a plan from SQL."
+description: "EXPLAIN, EXPLAIN ANALYZE and EXPLAIN VERBOSE: reading and measuring a plan from SQL."
 icon: map
 keywords: ["explain", "explain analyze", "explain verbose", "query plan"]
 ---
@@ -20,7 +20,7 @@ EXPLAIN ANALYZE SELECT * FROM documents WHERE identifier < 1000
 | `EXPLAIN VERBOSE <query>` | Adds intermediate optimizer plans on top of `EXPLAIN`. |
 
 The result is a small relation with `plan_type` and `plan` columns, read
-through the same client you use for regular queries -- see
+through the same client you use for regular queries. See
 [Connecting](/sql#connecting).
 
 SQL plans and the SDK's
@@ -46,7 +46,7 @@ SQL can also add joins, aggregates and other operators:
 | `FilterExec` above a search | the filter ran after search rather than pushing into it |
 | `ANNSubIndex` / `ANNIvfPartition` | the vector index was used |
 
-A `LanceScan` feeding a join is the common one worth acting on -- see
+A `LanceScan` feeding a join is the common one worth acting on. See
 [Joins](/sql/dql/join#performance).
 
 For a table's columns and types without a plan, see

docs/web/sql/dql/fts.mdx

@@ -1,7 +1,7 @@
 ---
 title: "Full-Text Search"
 sidebarTitle: "Full-Text Search"
-description: "The fts() table function — match, fuzzy, phrase, boolean, boost and multi-match queries from SQL."
+description: "The fts() table function: match, fuzzy, phrase, boolean, boost and multi-match queries from SQL."
 icon: magnifying-glass
 keywords: ["fts", "sql", "full text search", "fuzzy", "phrase", "boolean", "boost", "multi-match"]
 ---
@@ -9,7 +9,7 @@ keywords: ["fts", "sql", "full text search", "fuzzy", "phrase", "boolean", "boos
 <Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)
 
 Full-text search is a **table function**, `fts(table, query)`, rather than a
-predicate -- it produces a relevance score alongside the matching rows, and a
+predicate: it produces a relevance score alongside the matching rows, and a
 `WHERE` clause has nowhere to put one. The two string-literal arguments are
 the table name and a JSON-encoded query, built with the same query-builder
 classes used from the SDK and serialized with `.to_json()`.
@@ -32,8 +32,8 @@ CREATE INDEX ON my_docs USING fts (text);
 ```
 
 <Warning>
-Phrase queries need position information, which costs extra index size --
-add `WITH (with_position = true)` to `CREATE INDEX`. Without it,
+Phrase queries need position information, which costs extra index size.
+Add `WITH (with_position = true)` to `CREATE INDEX`. Without it,
 [phrase queries](#phrase) find nothing. See
 [FTS parameters](/indexing/fts-index#fts-parameters).
 </Warning>
@@ -57,7 +57,7 @@ FROM fts('my_docs', '{"match":{"column":"text","terms":"puppy"}}')
 LIMIT 5
 ```
 
-By default the top 5 matches come back in **arbitrary order** -- select
+By default the top 5 matches come back in **arbitrary order**. Select
 `_score` and order by it for relevance ranking:
 
 ```sql
@@ -126,8 +126,8 @@ MultiMatchQuery("puppy", ["text", "category"], boosts=[2.0, 1.0])  # text weight
 
 ## Combining with SQL {#combining}
 
-`fts()` is a relation, so it composes with the rest of the SQL surface --
-filter, join, or aggregate over it same as any table:
+`fts()` is a relation, so it composes with the rest of the SQL surface.
+Filter, join, or aggregate over it same as any table:
 
 ```sql
 SELECT id, text, category

docs/web/sql/dql/join.mdx

@@ -24,14 +24,14 @@ JOIN categories AS c ON c.id = d.category_id
 | `LEFT [OUTER] JOIN` | every left row, nulls where the right has no match |
 | `RIGHT [OUTER] JOIN` | every right row |
 | `FULL [OUTER] JOIN` | every row from both |
-| `CROSS JOIN` | every combination -- the product of the two |
+| `CROSS JOIN` | every combination (the product of the two) |
 
 `USING (col)` is shorthand for an equality join on a shared column name, and
 avoids repeating it in the select list.
 
 ## Across namespaces {#namespaces}
 
-Tables in different [namespaces](/management/namespace) join by their dotted paths -- the
+Tables in different [namespaces](/management/namespace) join by their dotted paths. The
 catalog is one catalog, so there is nothing to federate:
 
 ```sql
@@ -56,7 +56,7 @@ ORDER BY hits DESC
 ```
 
 That composition is the reason full-text search is a relation rather than a
-predicate -- a `WHERE` clause has nowhere to put the relevance score.
+predicate: a `WHERE` clause has nowhere to put the relevance score.
 
 ## Performance {#performance}
 

docs/web/sql/dql/sampling.mdx

@@ -35,7 +35,7 @@ SELECT * FROM documents TABLESAMPLE SYSTEM (10)
 | `SYSTEM` | `BLOCK` | **Lance fragments**, and takes whatever rows they hold |
 
 `BERNOULLI` gives a genuinely uniform sample and reads across the whole table to
-get it. `SYSTEM` reads far less -- it skips entire fragments -- but the sample is
+get it. `SYSTEM` reads far less (it skips entire fragments), but the sample is
 only as uniform as the data's layout. If rows were written in an order that
 correlates with what you are measuring, a fragment sample inherits that
 correlation.
@@ -46,7 +46,7 @@ independent row sampling. Omitting the method gives
 
 ## Repeatability {#repeatable}
 
-Without a seed, every execution resamples -- running the same query twice gives
+Without a seed, every execution resamples: running the same query twice gives
 different rows. `REPEATABLE` fixes the draw:
 
 ```sql
@@ -98,5 +98,5 @@ would draw from are not all in the fragments yet.
 ## Sampling outside SQL {#sdk}
 
 For a training loop rather than a query, the SDKs read a table in a shuffled
-order without going through SQL at all -- see [Training](/training/data-loading), where a
+order without going through SQL at all. See [Training](/training/data-loading), where a
 permutation drives the data loader.

docs/web/sql/dql/select.mdx

@@ -107,8 +107,8 @@ A CTE is scoped to the statement. One you want to keep is a
 
 ## Subqueries {#subqueries}
 
-Subqueries are allowed anywhere an expression or a relation is -- in `FROM`, in
-`WHERE` with `IN` or `EXISTS`, and as a scalar in the select list:
+Subqueries are allowed anywhere an expression or a relation is (in `FROM`, in
+`WHERE` with `IN` or `EXISTS`, and as a scalar in the select list):
 
 ```sql
 SELECT title

docs/web/sql/dql/window.mdx

@@ -89,7 +89,7 @@ WITH ranked AS (
 SELECT * FROM ranked WHERE rn = 1
 ```
 
-The outer query is needed because a window function cannot appear in `WHERE` --
+The outer query is needed because a window function cannot appear in `WHERE`:
 windows are computed after filtering, so the predicate would have nothing to
 read.