fix(base): spell File's types the way the rest of base does

[Force67]

base/filesystem/file.h names uint8_t, uint32_t and int64_t across its
signatures and includes nothing that declares them. They arrived transitively
until base stopped pulling <cstdint> in for its own use (#14), so whether a
build survives now depends on the standard library it meets:

toolchain	devel5
gcc 15.2 (nixpkgs)	builds — the types land through another include
gcc 13.4 / 13.3 (ubuntu 24.04)	fails

base/filesystem/file.h:134:26: error: 'uint32_t' has not been declared
base/filesystem/file.h:192:48: error: 'uint8_t' was not declared in this scope

and the Span<uint8_t> signatures below collapse into ~40 further diagnostics.
A consumer on ubuntu 24.04 cannot build devel5 at all — which is how it
surfaced: a downstream CI job went red at the commit that pinned equilibrium
forward, on the runner's gcc 13.3, while the same tree built fine locally on
gcc 15.

Not by adding the include back

The reflex fix is #include <stdint.h>, and it would work. But base already has
these types — u8, u32, i64, mem_size from base/arch.h, a header that
by its own comment "may never include other files" — and 54 of the 56
headers in base that name a fixed-width type already use them. file.h was
one of the two stragglers. Adding a C header back into base one commit after
#14 took the C runtime out of it is pulling in the wrong direction.

So File's surface is spelled the way its neighbours are, and the platform
definitions in posix/file_posix.cc and win/file_win.cc follow the
declarations. Casts and locals inside those files keep size_t and friends,
which is correct — that code is talking to POSIX and Win32.

base/hashing/crc.h is the other straggler, with the same gap and no failure
yet: its uint32_t arrives only through whichever of <nmmintrin.h>,
<intrin.h> or <arm_acle.h> the #if chain selects, and a target matching no
branch gets none of them.

The result is no C fixed-width type left in a base public signature, and no new
include to carry.

Verification

Library and tests build clean and all four test binaries pass on gcc 13.4
and gcc 15.2. file_win.cc is a textual conversion I could not compile
here; its definitions were diffed against the header signature by signature.