feat(arxjit): resolve a compilable signature from Python annotations

[Jaskirat-s7]

Follows #102. Closes the remaining open question in wiki Issue 2: "decide how Python annotations interact with explicit signatures."

The rules

New arxjit.reconcile decides which Signature a validated function will be compiled against:

given	result
explicit signature=	wins outright; annotations are not read at all
annotations only	signature derived from them
neither	reported at WARNING severity, function stays interpreted
some annotations, others missing or unsupported	every remaining gap is an ERROR

Because an explicit signature short-circuits, a function may annotate freely without having to agree with it — there is deliberately no mismatch error, per the decision in the thread. The last row is the judgement call worth flagging: once a function annotates anything, it is read as asking to be compiled, so a gap elsewhere is an error rather than a silent fallback.

Annotations are read from the ast, not __annotations__

A module using from __future__ import annotations turns every annotation into a string at runtime, which would otherwise have to be evaluated back with eval_str. Reading the ast makes that irrelevant, and lets each diagnostic point at the exact annotation that caused it rather than at the function.

Only a bare int, float or bool is accepted; a subscripted (list[int]), dotted (np.float64) or quoted ("int") annotation is reported against its own location. One consequence worth naming: this can never produce i32 or f32, since Python has no annotation that distinguishes widths, so the narrow types stay explicit-signature only. That partly answers the "should we trim i32/f32?" question from #91 — they remain reachable, just not from annotations.

Positional-only parameters are included in the derived signature. Validation permits them and they are ordinary positional arguments to a compiled function, so leaving them out would silently drop an argument.

Fail-closed on argument shapes

Signature is a fixed list of positional argument types, so a variadic or keyword-only parameter has nowhere to go. Validation rejects those shapes first, which makes this unreachable through @jit — but resolve_signature is exported, and without a check it would leave the parameters out and hand back a signature that is quietly wrong (i64() for a function taking *args). It now reports that it cannot derive one instead. Four regression tests cover *args, **kwargs, keyword-only, and the mixed positional-plus-variadic case.

Location helpers moved

_char_column and _diagnostic move out of validation.py into a new arxjit.locations, now that a second stage builds diagnostics from ast nodes. Single-sourcing them keeps the two stages from drifting on the column contract (one-based Unicode characters, converted from ast's zero-based UTF-8 byte offsets at the boundary). No behaviour change — a move, plus a severity parameter so reconciliation can emit WARNING.

Note on scope

resolve_signature is exported and fully tested but not yet consulted by @jit — core.py is untouched here. Wiring it into the decorator, along with the strict flag and the warn-and-fall-back behaviour, is the next PR. Splitting it this way keeps the resolution rules reviewable on their own, separately from the decorator behaviour change.

Verification

169 tests, arxjit coverage 100%. All gates green locally: pytest+cov, ruff format/check, mypy strict (cd packages/arxjit && mypy src), bandit -iii -lll, vulture 80, mccabe 10, douki sync idempotent. Verified on CPython 3.10.19, 3.11.11 and 3.14.6.