Expose EmbeddingGemma's tokenizer, as CoreMLLLM already does

[gen-0s]

EmbeddingGemma.load builds an AutoTokenizer from hf_model and keeps it private. A caller that needs a token count has no way to reach it.

That count is not a nicety for this model: encode truncates at config.maxSeqLen silently —

var ids = tokenizer.encode(text: prefixed)
let L = config.maxSeqLen
if ids.count > L { ids = Array(ids.prefix(L)) }

— no throw, no flag, and the published embeddinggemma-300m-coreml bundle sets max_seq_len to 128. Anything longer is indexed as its first ~128 tokens and reports success. Splitting text into windows before calling encode is the fix, and that needs to know how many tokens a span costs.

Today the only way to get that is to build a second AutoTokenizer over the same folder this instance already read. For EmbeddingGemma's 262,144-entry vocab and 514,906 merges that measures 1.9 s and +92 MB in our app, duplicating an object already resident in the process.

CoreMLLLM in this same package already solves exactly this, at Sources/CoreMLLLM/CoreMLLLM.swift:161-163:

/// Expose the tokenizer so a harness can re-encode / decode arbitrary
/// text without duplicating the swift-transformers wiring.
public var tokenizerRef: any Tokenizer { tokenizer }

This PR is that accessor on EmbeddingGemma, for the same reason. One line plus a doc comment; no behaviour change, no new dependency, nothing else touched.

Happy to also send a follow-up making the truncation visible (returning the token count, or throwing when ids.count > L) if you'd take it — that's the underlying defect, and this accessor only lets callers work around it.