- Extract shared `encode_base40_fixed<N>` generic helper to eliminate
  duplication between `encode_base40` and `encode_base40_128`
- Export `BASE40_LEN_64` and `BASE40_LEN_128` constants for the full
  hash string widths
- Add comments at truncation sites documenting the approximate
  bit-strength of each truncated hash
- Extract `short_hash` variable in asset_path methods to avoid
  repeating the truncation slice in both format! arms
- Update module doc comment to mention base40 encoding

Match chunk filename hash length (13 base40 chars ≈ 69 bits) for asset
filenames instead of the previous 7-char truncation.

…variable names containing invalid identifier characters (`-`, `~`, `.`), causing syntax errors in generated WASM loader code.

This commit fixes the issue reported at turbopack/crates/turbopack-wasm/src/lib.rs:29

**Bug explanation:**

The `wasm_edge_var_name` function generates a JavaScript variable name of the form `wasm_{hash}`. This variable name is interpolated directly into JavaScript code in `loader.rs` at two call sites (lines 51 and 78), appearing in expressions like:

```js
const { exports } = await __turbopack_wasm__(wasmPath, () => wasm_abc123, imports);
```

and:

```js
const mod = await __turbopack_wasm_module__(wasmPath, () => wasm_abc123);
```

The hash algorithm was changed from `Xxh3Hash128Hex` to `Xxh3Hash128Base40`. The base40 alphabet is `0123456789abcdefghijklmnopqrstuvwxyz_-~.`, which includes `-`, `~`, and `.` — characters that are NOT valid JavaScript identifier characters. A 25-character base40 hash has approximately an 87% chance of containing at least one of these three characters, making this effectively a guaranteed failure.

For example, a generated variable name like `wasm_abc-def~ghi.jkl` would produce invalid JavaScript:
```js
() => wasm_abc-def~ghi.jkl  // SyntaxError: `-` is subtraction, `~` is bitwise NOT, `.` is property access
```

**Fix explanation:**

Reverted the hash algorithm for `wasm_edge_var_name` back to `Xxh3Hash128Hex`, which only produces `0-9a-f` characters — all valid in JavaScript identifiers. Other base40 usages (for filenames, version strings, output asset paths) are correct and left unchanged, as the base40 alphabet is URL-safe and filesystem-safe for those contexts.

Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: sokra <tobias.koppers@googlemail.com>

…to base64

- Move ContentHashing enum from turbopack-browser to turbopack-core
  so both Browser and NodeJs chunking contexts can use it
- Rename content_hashing -> chunk_content_hashing in BrowserChunkingContext
- Add separate asset_content_hashing field to both BrowserChunkingContext
  and NodeJsChunkingContext
- Rename builder method use_content_hashing() -> chunk_content_hashing()
- Add builder method asset_content_hashing()
- Switch all version hashes from base40 to base64 encoding since
  version identifiers don't need URL/filesystem safety
- Add encode_base64 helper for u64 -> base64 encoding

asset_content_hashing is always needed for asset paths, so make it a
plain ContentHashing instead of Option<ContentHashing>. Defaults to
ContentHashing::Direct { length: 13 } (69 bits of collision resistance).

Regenerate all Turbopack snapshot test files to match new base40 hash
format. Update test helper regexes (stripTestHash, stripVercelPngHash)
and inline patterns from [0-9a-f] to [0-9a-z_.~-] to match the base40
character set.

…age hashes

Co-Authored-By: Claude <noreply@anthropic.com>

…oded comment

- Remove `.asset_content_hashing(ContentHashing::Direct { length: 13 })` from
  BrowserChunkingContext builder since 13 is already the default
- Remove hardcoded "13 base40 chars" comments from asset_path() in both
  BrowserChunkingContext and NodeJsChunkingContext since length is now dynamic