Upgrade lindera dependency from 2.0.1 to 5.0.1

[mosuka]

Summary

• Move from lindera = "2.0.1" to lindera-analysis = "5.0.1". lindera 5.0.0 split the tokenizer/analysis-chain API (character filters, token filters, TokenizerBuilder/Tokenizer) out of the lindera crate into a new lindera-analysis crate; the pure segmenter stays in lindera. The API surface (TokenizerBuilder::new()/.build(), Tokenizer::tokenize(), Token.surface/.byte_start/.byte_end), the LINDERA_CONFIG_PATH env var, and the YAML config schema are all unchanged, so src/lib.rs/src/common.rs only needed an import-path swap — no tokenization logic changed.
• Rework embed-* Cargo features to forward through lindera-analysis, and add embed-jieba.
• Fix CI's test step (--all-features → --features=embed-cjk) and a release.yml config-path typo; document which dictionary each embed-* feature embeds in the README.

Breaking changes

1. embed-cjk now embeds Jieba instead of CC-CEDICT for Chinese. This mirrors upstream lindera 5.0.1's own embed-cjk definition (IPADIC + ko-dic + Jieba, changed from IPADIC + ko-dic + CC-CEDICT in lindera 2.x). Since lindera 5.x gates DictionaryKind::CcCedict behind the embed-cc-cedict feature specifically, anyone with dictionary: "embedded://cc-cedict" in their lindera.yml who builds with embed-cjk needs to either switch to the standalone embed-cc-cedict feature build, or repoint their config at embedded://jieba.
2. Built artifacts are significantly larger. lindera 5.0.0 dropped the compress feature entirely (dictionaries are now embedded uncompressed for rkyv zero-copy loading). Locally, the embed-cjk release binary grew from 41.9 MB to 234 MB (~5.6x).

Why --all-features → --features=embed-cjk in CI

--all-features would now build all 6 dictionaries uncompressed in a single CI job. Upstream lindera itself hit disk-space failures embedding even a single uncompressed dictionary per job (lindera#752) and had to add cleanup steps. Per-dictionary build coverage is already provided by this workflow's existing build job matrix (one job per embed-* feature), so switching the test job to embed-cjk only doesn't reduce coverage, just avoids stacking all 6 dictionaries in one job across 6 platforms including macOS/Windows.

Test plan

• cargo build --features=embed-cjk
• LINDERA_CONFIG_PATH=./resources/lindera.yml cargo test --features=embed-cjk — 2 tests + 1 doctest pass, including it_emits_segments's exact byte-offset assertions (the main regression risk, since OffsetMapping::correct_offset was internally rewritten upstream between v2 and v5)
• Each embed-* feature builds standalone with no cross-dependency
• cargo fmt --all -- --check clean; cargo clippy --features=embed-cjk has one pre-existing warning in src/extension.rs, untouched by this PR
• End-to-end: loaded the built extension into a real sqlite3 session, created an FTS5 table, inserted Japanese text, confirmed MATCH returns correct results. (Loading against unpatched main currently fails due to the unrelated, already-open Extension fails to load on SQLite >= 3.47: fts5_api.iVersion is 3, but init requires exactly 2 #34 bug — reproduced identically on both main and this branch to confirm this PR isn't the cause; verified tokenization end-to-end with Extension fails to load on SQLite >= 3.47: fts5_api.iVersion is 3, but init requires exactly 2 #34's fix applied temporarily, then reverted before committing here since fixing Extension fails to load on SQLite >= 3.47: fts5_api.iVersion is 3, but init requires exactly 2 #34 is out of scope for this PR.)

Closes #35