[Siddhesh2377]

Adds Flint (FlintForCausalLM, unsloth/flint-GGUF) to the fork. Three commits for Flint, plus one CI fix:

• 2878f634 cherry-picks upstream llama : scale moe down projection per expert token ggml-org/llama.cpp#30861. Flint's MoE path calls build_amax_src1_f16, which isn't in the fork yet. It also replaces the old ggml_prec_set_src(F32) line for Mistral4 with upstream's graph-level rescale, so Mistral4 and Mellum change behaviour here.
• 808825f9 cherry-picks the Flint PR, models: Add Flint model (FlintForCausalLM) ggml-org/llama.cpp#30928 at 1b44e307. That PR is approved upstream but not merged. Conflicts were resolved by adding only LLM_ARCH_FLINT, not the upstream-only archs that sat next to it.
• cb858de7 is a port fix. Upstream adds logits to the graph in a shared build_logits(), and the fork's model files still do it themselves. Without this line every Flint decode asserts at llama-context.cpp:1956. Drop this commit when the fork syncs past build_logits().

Both cherry-picks carry -x trailers, so the next upstream sync can drop them.

Tested on an M4 Pro (48 GB), Metal:

Check	Result
test-llama-archs -a '^flint$'	4/4 OK
full test-llama-archs, excluding deberta*	514/514 OK
tokenizer vs HF RecursiveSI/flint	10/10 lines identical
llama-server chat, UD-Q4_K_XL	correct output, reasoning split out, stops on EOG, about 54 tok/s
3,275-token prompt (past the 513 SWA window)	recalled a code from the start exactly
context shift, -c 1024, 1,600 tokens	no crash, output stays coherent
perplexity, wikitext-2, ctx 512, 20 chunks	22.81 ± 1.29
tool call	parsed into tool_calls

Two known gaps. Flint's embedded chat template uses replace("\x00", ""), and the Jinja lexer here and upstream rejects \x escapes, so --jinja fails at start-up unless you pass a template with that filter removed via --chat-template-file. That fix belongs upstream. Separately, deberta-v2 aborts in the test-llama-archs model generator with a missing relative_pos_max key. Plain ra/main (a8ea71dc) fails the same way, so that's an existing problem.

d37c473e fixes the pre-tokenizer-hashes check, which has been red on the fork since c6aa47c6. The GLiNER2.5 hash was hand-added to conversion/base.py, so the generator dropped it on every run. It's now registered in convert_hf_to_gguf_update.py with its source repo, fastino/GLiNER2.5-Decide, which I confirmed by recomputing the hash. Running the generator twice gives the same file. The flake8 Lint failures are also older; they're in conversion/bert.py and gguf-py/gguf/constants.py lines from c6aa47c6.