fix(detect): classify sequence-classification heads by what MLXRerankers can score, never as embedders

[magicnight]

Closes #131.

A *ForSequenceClassification checkpoint is now classified in one place, by what MLXRerankers can actually do with it, and never falls through to the model_type rules:

config	before	now
bert / roberta / xlm-roberta, one label (ms-marco-MiniLM, bge-reranker)	reranker	reranker
same types, several labels, one of them a positive class upstream recognizes (entailment, relevant, positive, yes, LABEL_1, …; the 3-way NLI cross-encoders)	embedder, served as 19,968-d "vectors"	reranker, scored as that class's probability
same types, several labels, no such class (a 5-label sentiment head)	embedder	plain .mlx
any other model_type with the head: electra, Qwen3ForSequenceClassification conversions, no model_type at all	Rerank badge, then 500 from the factory	plain .mlx (the existing 400 on /v1/rerank)

Label handling mirrors upstream's BertConfiguration: id2label first, label2id filling gaps, num_labels defaulting to the highest id plus one.

Verification

• Detection suite: 23 tests (six replaced or added for the new cases). Six mutations of the rule — the model-type gate, the positive-class test, the .mlx-not-.embedder outcome, the label2id merge, the num_labels default, contains vs first on architectures — each turn exactly the expected tests red.
• Route test: /v1/embeddings answers 400 model_not_embedder for a .reranker.
• Gated smoke (new, cross-encoder/nli-MiniLM2-L6-H768, 313 MB), run with the other three: the real config.json scans as .reranker, the engine loads it through MLXRerankers, and the entailment probabilities come out 0.0033 and 0.0028 for the two Berlin-population passages against 0.0013 and 0.0008 for the two unrelated ones. The absolute values are small because an NLI head measures entailment of a statement by a question, not relevance; the ordering is what the test asserts. ms-marco (1.9e-6 against PyTorch with TF32 off), Qwen3-Reranker-0.6B-4bit and the end-to-end /v1/rerank test are unchanged.

Review round (second commit)

• RoBERTa tokenizers scored a different input. The critic found that swift-transformers 1.3.4's RobertaProcessing ignores addSpecialTokens: false and always wraps in <s> … </s>, while mlx-swift-lm's pair encoder encodes each segment bare and adds the special tokens itself, so every RoBERTa-tokenizer reranker saw a doubly wrapped input (the NLI numbers in the first round, 0.0028 / 0.0008 / 0.0033 / 0.0013, were exactly PyTorch's output for that wrong input; the correct ones are 0.0046 / 0.0004 / 0.0036 / 0.0012, top-1 flipped). TokenizerBridge.encode now bypasses the post-processor when no special tokens are wanted. An ungated test with a three-word RoBERTa tokenizer fixture fails on the old bridge; the NLI smoke now compares entailment probabilities with a PyTorch reference (new fixture + capture script): worst relative error 7.4e-6 with TF32 off, 1.8% under M5's default TF32 (gates 1e-4 and 5%). ms-marco (1.9e-6) and Qwen3 are unchanged, so the bypass did not touch BERT or Qwen tokenization. Affected on main since feat(rerank): run /v1/rerank on mlx-swift-lm's MLXRerankers #129: stsb-roberta-base, quora-distilroberta-base and the nli-*roberta* heads.
• Positive-class rule narrowed below upstream's. positive and LABEL_1 count only on a two-label head; on 3- or 5-way heads they are sentiment classes (negative / neutral / positive, transformers' default LABEL_0…n) and upstream would serve P(positive sentiment) as relevance. mrm8488/distilroberta-finetuned-financial-news-sentiment-analysis is a real checkpoint of that shape and now stays .mlx. Four more fixtures, four more mutations each red (binary-only rule applied to any count, dropped, contains → last, highest-id → count).
• Stale single-logit comments rewritten, the detection temp dir now cleans up, smoke header lists the NLI checkpoint. Full pure suite 977/102 green.