[Docs] Refine section titles and structure

- Rename 'Differences from OpenSearch SQL V2 (Legacy)' to
  'Migrating from SQL V2'; reframes the section around the user task
  (moving queries from V2 to the new engine).
- Rename 'Query-shape extensions' to 'Query syntax extensions'; less
  jargon.
- Rename 'Catalog statement differences' to 'Metadata statement
  differences'; matches the terminology already used in V2's own
  docs/user/dql/metadata.rst.
- Update the 'Differences from Standard SQL' intro sentence to state
  the actual driver of the deviations: each exists to keep queries
  that worked on OpenSearch SQL V2 working unchanged on the new
  engine.
- Merge the single-row 'Operator differences' section (INTERVAL NULL
  DAY) into 'Lexical and literal differences' where it fits
  naturally.
- Remove the empty 'Semantic differences' section.

Signed-off-by: Chen Dai <daichen@amazon.com>

Author: dai-chen

docs/user/general/sql-compatibility.rst

@@ -63,8 +63,8 @@ Lexical and identifier extensions
 
       SELECT `name` FROM employees
 
-Query-shape extensions
-----------------------
+Query syntax extensions
+-----------------------
 
 * **GROUP BY by select-list alias.** A ``GROUP BY`` item may refer to a select-list
   alias as well as a column::
@@ -106,8 +106,8 @@ Full-text search extensions
 Differences from Standard SQL
 =============================
 
-The following are deliberate deviations from ANSI SQL, adopted to preserve
-OpenSearch-idiomatic behavior.
+The deviations below are not design choices in isolation — each exists to keep
+queries that worked on OpenSearch SQL V2 working unchanged on the new engine.
 
 * **Double-quoted identifiers vs. string literals.** ANSI SQL reserves double
   quotes for identifiers. OpenSearch SQL follows BigQuery conventions: some
@@ -133,8 +133,8 @@ OpenSearch-idiomatic behavior.
   full-text search function has a natural function-call form.
 
 
-Differences from OpenSearch SQL V2 (Legacy)
-===========================================
+Migrating from SQL V2
+=====================
 
 The following constructs are accepted by the legacy V2 engine but are **not**
 accepted by the new dialect. Where a standard-SQL equivalent exists,
@@ -170,6 +170,9 @@ Lexical and literal differences
    * - ``multi_match([f1, f2], 'text')``
      - Square-bracket field lists are not supported. Use standard function-argument
        form.
+   * - ``INTERVAL NULL DAY``
+     - ``INTERVAL`` requires a numeric literal or expression, not ``NULL``. Use
+       ``CAST(NULL AS INTERVAL DAY)`` if a null interval is needed.
 
 Identifier differences
 ----------------------
@@ -476,19 +479,6 @@ a standard SQL equivalent where one exists.
    * - ``TYPEOF(x)``, ``TYPE(x)``, ``FIELD(x)``
      - No standard equivalent.
 
-Operator differences
---------------------
-
-.. list-table::
-   :header-rows: 1
-   :widths: 40 60
-
-   * - V2 syntax
-     - Comment
-   * - ``INTERVAL NULL DAY``
-     - ``INTERVAL`` requires a numeric literal or expression, not ``NULL``. Use
-       ``CAST(NULL AS INTERVAL DAY)`` if a null interval is needed.
-
 Clause and syntactic differences
 --------------------------------
 
@@ -509,11 +499,11 @@ Clause and syntactic differences
    * - ``FROM bank b1, b1.firstname``
      - Implicit nested-field joins via an alias path are not supported.
 
-Catalog statement differences
------------------------------
+Metadata statement differences
+------------------------------
 
-The following catalog-browse statements are not accepted. Catalog browsing is not
-part of the SQL surface in the new engine.
+The following metadata (catalog-browsing) statements are not accepted. Metadata
+browsing is not part of the SQL surface in the new engine.
 
 .. list-table::
    :header-rows: 1
@@ -543,13 +533,6 @@ Result-shape differences
      - ``EXPLAIN`` returns the physical query plan tree. The format is different
        from V2 and is considered internal to the new engine.
 
-Semantic differences
---------------------
-
-No semantic differences from V2 are known at this time. (V2's type system also
-requires the result types of a ``CASE`` expression's branches to be compatible;
-V2 and the new engine raise equivalent errors for incompatible branch types.)
-
 
 References
 ==========