/**
 * Expand user-shorthand prefixes in a path string. Currently:
 *
 * - `~` alone → `$HOME`
 * - `~/foo` (or `~\foo` on Windows) → `$HOME/foo`
 * - `~user/...` throws (POSIX-only; the platform complexity isn't
 *   worth the small payoff — also lets people write a literal
 *   `~user-typed-name` dir at the project root by quoting `./~user...`).
 * - everything else returns unchanged.
 *
 * This is the single owner of path-shorthand policy for the stdlib.
 * Future rules (env-var expansion, NFC normalization, etc.) land
 * here, not at call sites. Anything in `lib/stdlib/` that resolves
 * a user-typed path string MUST route through `resolvePath` /
 * `resolveDir`, which call this helper first — never re-implement
 * the policy locally.
 *
 * Layering: `expandPath` is intentionally a **pure string transform**
 * with no async, no ALS access, and no base-directory awareness. The
 * "resolve relative paths against the cwd" policy lives one layer
 * up: `resolveDir` (which also asserts allow-list containment) and
 * `resolvePath` for the dir+filename case (which deliberately
 * enforces no containment — callers that take `allowedPaths` layer
 * `assertContained` themselves). Keeping the layers
 * split means `expandPath` is trivially testable in isolation, and
 * each caller picks the base it wants without this helper having to
 * fan out into runtime context.
 *
 * Does NOT resolve to an absolute path — callers still pass the
 * result through `path.resolve` / `resolvePath` / `resolveDir`.
 *
 * `expandPath("")` returns `""` unchanged so empty-string sentinels
 * pass through (callers that disallow empty dir handle that
 * themselves with a clearer error).
 */
export declare function expandPath(p: string): string;