`/` and `div` semantics diverge between direct-eval and DAG-eval

[protocolstardust]

/ and div give different results depending on whether they run through the interpret mode kernel or the DAG-compiled kernel. Each individual code path is also inverted relative to the q convention.

Direct eval:

(/ 10.0 3.0)         => 3.0     ; expected 3.333… (true div)
(div 10.0 3.0)       => 3.333…  ; expected 3      (floor int div)

DAG eval (compiled SELECT over a table column):

; with table t having a F64 column x
(select {r: (/ x 3) from: t})        ; => 3.333…   correct
(select {r: (div x 3) from: t})      ; => domain error - `div` not registered in DAG

Expected (q convention)

op	semantics
/	true division. Always returns F64, e.g. 10.0/3.0 → 3.333…, 10/3 → 3.333…
div	integer floor division. Always returns I64, e.g. 10.0 div 3.0 → 3, 10 div 3 → 3

Both code paths must agree.

Actual

op	direct eval	DAG eval
/	floor	true division ✓
div	true division	domain error (op not registered in DAG)

Root cause

Two separate arithmetic kernels (src/ops/arith.c) plus the DAG-compiler op registry are out of sync:

1. The interpret-mode kernel for / floors before returning, instead of returning the unmodified quotient
2. The interpret-mode kernel for div returns the unmodified quotient, instead of truncating to int
3. The DAG kernel for / is correct (true div). The div op was never registered as a DAG op, so any compiled query using div is rejected by the type-check stage and bubbles up as a domain error