fix(driver): flatten build artifact paths

[ghaith]

Attribution: this branch, its tests and this description were produced by Claude
(Claude Code) working in my repository, not written directly by me. I have reviewed the
change, but please review it as machine-authored work. The commits carry a
Co-Authored-By: Claude trailer.

Fixes PRG-4448.

Problem

Every object, bitcode and IR artifact was named after the path of its source and created
under that path inside the build directory, so a source outside the project mirrored its
whole absolute path. The directory of the target was added twice on top of that, once by the
driver and once by GeneratedModule::persist.

On Windows a second problem compounded it: fs::canonicalize returns a verbatim path
(\?\C:\...) while the project root does not, so the comparison that selects the relative
name never matched and the absolute path was mirrored even for sources inside the project.

The result goes past the 260 characters the Windows file system allows without long path
support. The compiler itself does not fail, because the standard library hands absolute paths
to the file system in verbatim form, so the damage lands on everything else: the reporter of
PRG-4448 hit it copying their workspace in File Explorer.

Solution

Artifacts get a flat name of the form <file name>-<digest>.<extension>, for example
main.st-116b35a8828869ac.o, and all of them land directly in <build>/<target>/.

• The digest is a SipHash-1-3 of the whole key with a fixed zero key, so a name is identical
  on every run, process and platform. It is what keeps two units with the same file name in
  different directories apart now that they share one directory.
• The key of a unit is its path relative to the project, or its full path when it lives
  outside the project. The project root is canonicalized before the comparison, so the
  relative form is also reached on Windows.
• The directory of the target is added by the driver only. GeneratedModule::persist writes
  to the directory it is given.

The compiler now adds at most 70 characters to the build directory. Unchanged: the final
artifact of a link still lands in <build>/<target>/<output>, and the header generator still
writes next to the source or into the requested directory.

Validation on Windows

Ran the Eclipse tool's own compile command unchanged, varying only the compiler binary, with
the standard library at a 202-character delivery path outside the workspace:

	before	after
longest artifact path	445	233
xcopy of the build output	3 of 31 files, exit code 0	31 of 31

The old path reproduces the shape reported in the ticket, doubled target directory included.
The 3-of-31 copy is the reported failure: silent truncation with a success exit code.

Tests

compiler/plc_driver/src/tests/artifact_names.rs covers the naming, with platform dependent
scenarios mirrored between a linux and a windows module. tests/integration/build_artifacts.rs
covers the layout end to end, including a build through the build subcommand where the
project root comes from plc.json. Both suites already run in the Windows job.

The flat assertion, the character budget and the 260-character limit were each confirmed red
against the pre-fix code on Windows before this went in.

🤖 Generated with Claude Code

[github-actions]

Build Artifacts

🐧 Linux

Artifact	Link	Size
deb-x86_64	Download	40.8 MB
schema	Download	0.0 MB
stdlib	Download	39.4 MB
plc-x86_64	Download	43.5 MB
deb-aarch64	Download	31.9 MB
plc-aarch64	Download	43.4 MB

From workflow run