Refactor documentation: remove .md extensions from all internal links

and delete deprecated docs

Author: joocer

docs-site/content/docs/reference/sql/aggregates.md

@@ -1,6 +1,6 @@
 # Data API (deprecated)
 
-This page has been renamed to **Jobs API**. See [Jobs API](jobs-api.md).
+This page has been renamed to **Jobs API**. See [Jobs API](jobs-api).
 
 Base URL: https://jobs.opteryx.app
 

docs-site/content/docs/reference/sql/data-types.md

@@ -50,4 +50,4 @@ Because the whole program is known at compile time, the executor can pick a path
 
 ## In short
 
-The bytecode engine is the expression-evaluation core: it compiles each expression into a flat, postfix program once at bind time — materialising literals and binding kernels to function pointers up front — then executes that program over [Draken](draken.md) vectors morsel by morsel, with the GIL released wherever the whole expression is native. The planner does the thinking once; the data path just runs.
+The bytecode engine is the expression-evaluation core: it compiles each expression into a flat, postfix program once at bind time — materialising literals and binding kernels to function pointers up front — then executes that program over [Draken](draken) vectors morsel by morsel, with the GIL released wherever the whole expression is native. The planner does the thinking once; the data path just runs.

docs-site/content/docs/reference/sql/functions.md

@@ -4,7 +4,7 @@ Strings are the awkward case for a columnar engine. Numbers are fixed-width —
 
 Draken sidesteps most of that cost with a layout commonly called the *German string* (popularised by the Umbra and DuckDB teams). The idea: make every string occupy a fixed-width slot, and pack enough information into that slot that the most common operations — equality, ordering, length — usually finish without ever touching the variable-length bytes at all.
 
-This document explains that layout. For how strings (and every other column) are wrapped for execution, see [How Draken Stores Column Data](draken-vector-encoding.md).
+This document explains that layout. For how strings (and every other column) are wrapped for execution, see [How Draken Stores Column Data](draken-vector-encoding).
 
 ---
 
@@ -92,7 +92,7 @@ Operations like aggregation accumulate group keys by copying string slots from o
 
 That means **no re-derivation of the prefix** and no work proportional to the string's length beyond the byte copy itself. Re-homing a string key is essentially a 16-byte copy plus an arena append.
 
-Because a long slot holds an *offset* rather than a pointer, slots and arena are also byte-for-byte relocatable as a pair — which is what lets a string column be written to disk and read back without rebuilding anything (see [Skene](skene.md)).
+Because a long slot holds an *offset* rather than a pointer, slots and arena are also byte-for-byte relocatable as a pair — which is what lets a string column be written to disk and read back without rebuilding anything (see [Skene](skene)).
 
 ---
 

docs-site/content/docs/reference/sql/null-semantics.md

@@ -30,7 +30,7 @@ Predicate evaluation becomes even cheaper than the memory saving suggests. To te
 
 Parquet's RLE_DICTIONARY encoding on disk maps directly to this shape in memory. There is no expansion step at read time.
 
-The values inside a string dictionary — and inside any string column — have their own fixed-width layout; see [How Draken Stores Strings](draken-german-strings.md).
+The values inside a string dictionary — and inside any string column — have their own fixed-width layout; see [How Draken Stores Strings](draken-german-strings).
 
 ### Constant
 

docs-site/reference/api/data-api.md

@@ -2,15 +2,15 @@
 
 Draken is the columnar vector library at the centre of Opteryx. Every column of data in the engine — whether freshly read from a file, produced by a join, or returned from an expression — is a Draken vector. It is the common currency that lets the scan, the operators, and the expression engine all speak the same language, across the Python, Cython, and C++ boundaries.
 
-Draken has **zero external dependencies**, and it ships inside both the Opteryx SQL engine and the standalone [Rugo](rugo.md) file engine. It is never published on its own; it travels as part of whatever uses it.
+Draken has **zero external dependencies**, and it ships inside both the Opteryx SQL engine and the standalone [Rugo](rugo) file engine. It is never published on its own; it travels as part of whatever uses it.
 
 ---
 
 ## One vector, one access pattern
 
 The core idea is that all columnar data is represented by a single struct, the **DrakenVector**, and every consumer reads it the same way. A vector pairs a buffer of values with a *selection* — a list of indices — and the value of logical row `i` is always `data[selection[i]]`. That one access pattern is the correctness contract: any kernel written against it produces the right answer for every vector it is handed.
 
-This uniform access is what lets the same vector quietly carry three very different physical layouts — a fully materialised *dense* column, a *constant* broadcast of one value, or a *dictionary* of distinct values plus per-row codes — without operators needing to branch on which is which. That layout story is told in full in [Draken vector encoding](draken-vector-encoding.md), and the way strings in particular are stored has its own page in [Draken string storage](draken-german-strings.md).
+This uniform access is what lets the same vector quietly carry three very different physical layouts — a fully materialised *dense* column, a *constant* broadcast of one value, or a *dictionary* of distinct values plus per-row codes — without operators needing to branch on which is which. That layout story is told in full in [Draken vector encoding](draken-vector-encoding), and the way strings in particular are stored has its own page in [Draken string storage](draken-german-strings).
 
 The struct's memory layout is **frozen**: a large number of compiled call sites bind its field offsets at compile time, so the engine pins the layout with compile-time assertions. A silent reordering of its fields would not fail the build — it would corrupt data — so the layout is guarded rather than trusted.
 
@@ -51,4 +51,4 @@ Code that consumes Draken does so through a typed Cython surface and a small C++
 
 ## In short
 
-Draken is the substrate everything else stands on: one frozen vector struct, one access pattern, one type vocabulary, and a native kernel library that computes over all of it. Rugo fills vectors from files; the [bytecode engine](bytecode-engine.md) evaluates expressions over them; the operators join, group, and sort them — but they all agree, because they all speak Draken.
+Draken is the substrate everything else stands on: one frozen vector struct, one access pattern, one type vocabulary, and a native kernel library that computes over all of it. Rugo fills vectors from files; the [bytecode engine](bytecode-engine) evaluates expressions over them; the operators join, group, and sort them — but they all agree, because they all speak Draken.