Add canonical config path resolvers

[yslib]

Summary

• canonicalize the selected configuration entry eagerly while retaining both entry and filesystem-entity path facts
• add ${dot:real_config} and ${dot:real_config_dir} and centralize DotPaths construction from LoadedConfig
• preserve existing ${dot:config}, ${dot:config_dir}, diagnostics, reports, and entry-relative Link.source behavior
• document entry/entity semantics, dry-run boundaries, non-Unicode resolution, and Windows verbatim-path handling

Why

A .dot.toml entry may be a symbolic link stored under the platform-standard user configuration directory while repository resources live beside the linked file's real entity. The new resolvers let configurations opt into repository-relative paths without changing the established meaning of the selected entry path.

User impact

Configurations can use ${dot:real_config_dir} for scripts and link sources that should follow a symlink to the repository. Existing configurations remain entry-relative unless they explicitly adopt the new resolver. Broken or otherwise unresolvable configuration entries now fail during loading because the configuration entity is canonicalized before reading.

On Windows, canonical paths retain the OS-provided \\?\ spelling. Backslash suffixes should therefore be written with TOML literal strings.

Validation

• cargo test --locked --all-targets --all-features
• cargo clippy --locked --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check
• cargo check --locked --target x86_64-pc-windows-gnu --all-targets --all-features using the matching rustup compiler
• five symlink-entry dry-runs against the companion dotfiles configuration: Arch root/desktop/laptop, macOS, and Windows
• git diff --check