Build: tinyvec 1.13.0 breaks cold unlocked dependency resolution

[developer0hye]

Problem

A fresh checkout without Cargo.lock resolves tinyvec 1.13.0 and fails before office2pdf compiles:

error: cannot find macro `vec` in this scope
  --> tinyvec-1.13.0/src/tinyvec.rs:710:21

The dependency graph enables tinyvec's alloc feature without its std feature through fontdb / unicode-normalization. tinyvec 1.13.0 accidentally calls an unqualified vec! macro in that configuration.

This currently leaves multiple otherwise-valid office2pdf PRs red, including the cold unlocked Publish Verification job.

Upstream tracking:

• vec macro import error with 1.13.0 Lokathor/tinyvec#225
• Fix no std with alloc Lokathor/tinyvec#226

Proposed bounded workaround

Because office2pdf is already std-only, explicitly enable tinyvec's std feature in the published office2pdf crate. Cargo feature unification then avoids the broken no_std + alloc code path for both workspace builds and downstream consumers. Remove the direct feature-unification dependency after a patched tinyvec release is available and verified.

Acceptance criteria

• A fresh unlocked cargo check --workspace resolves crates.io tinyvec 1.13.0 and passes.
• Native tests, formatting, and clippy remain green.
• All three wasm32-unknown-unknown check configurations remain green.
• Package/publish verification includes the workaround in the normalized published manifest.
• Existing dependency-blocked PRs are updated and rerun after this lands.

[developer0hye]

Resolved upstream: Lokathor/tinyvec#226 merged as 85f21c68b65d8a9db2426436a7c014658e669fc8 and tinyvec 1.13.1 is published. A fresh unmodified main checkout without Cargo.lock resolved and compiled tinyvec 1.13.1 successfully with cargo check --workspace, so no downstream workaround needs to land. I am rerunning every office2pdf PR attempt that failed on 1.13.0.