fix(fileutils): prevent stack buffer overflow in AbsPath

[Rakdos8]

Problem

AbsPath (POSIX path, used by CcpGetAbsolutePath) wrote into char[PATH_MAX] buffers with no bounds checking.
getcwd(src, …) followed by strcat(src, path) overflows the stack when cwd + path exceeds PATH_MAX (1024 on
macOS); src[len] = '/'; src[len+1] = 0; writes out of bounds when len == PATH_MAX-1; and strcpy(src, path)
(absolute path) plus strcpy(realPath, path) (on getcwd failure) are unbounded too. This is reachable on macOS (a
primary CI target) via CcpGetAbsolutePath, so it is a high-severity stack overflow driven entirely by path length.

Fix

AbsPath now receives the output buffer size (size_t realPathSize) — there is a single internal caller. src is
built with a bounded snprintf and the function returns an empty string when the combined path does not fit. The
getcwd failure path uses strncpy_s(…, _TRUNCATE) instead of strcpy, and there is an explicit guard before
writing into realPath. CcpGetAbsolutePath drops a dead line (a strcpy_s that was immediately overwritten) and
its unused variable, and now passes sizeof(buffer). Added #include <cstdio> in the POSIX block. Contract: when a
path is too long to fit, the function returns an empty string instead of overflowing.

Tests

Added two regression tests in tests/CcpFileUtils.cpp (GoogleTest, #if !_WIN32):
CcpGetAbsolutePathHandlesOverlongRelativePathSafely and CcpGetAbsolutePathHandlesOverlongAbsolutePathSafely, both
using 64 KB paths and expecting an empty result with no crash. Existing path-resolution tests are unaffected. Reviewed
manually; not compiled locally as the vcpkg toolchain is unavailable in this environment.

Scope

POSIX branch only — the Windows path uses GetFullPathNameW and is unchanged. No public API change.

[CCP-Aporia]

Hi @Rakdos8

Thank you for the PR and apologies for the late response. We are still in the process of sorting out some details around contribution guidelines and PR templates.

This is a good catch! There might even be a possibility to simply use realpath() directly instead of the custom AbsPath implementation that is currently used. But this PR also resolves the issue. I'll get back to you once we are in a position to accept contributions.

[Local9]

An AI Pull Request if I've ever seen one, looked over most of them from this user and they all smell of AI slop.

@CCP-Aporia I hope Fenris are going to add in some strong PR standards.

https://www.youtube.com/watch?v=uZy1M_s-8zs

[CCP-Gravy]

We care less about the tools used and more about the quality of code - low effort/ low quality PRs will always be rejected. We are working internally on the best way for us to voice our expectations when it comes to quality, and perhaps we are partially to blame if we have low effort PRs open at the moment.

As for this specific pull request; Lets keep PR discussion focused on the contents of the diff going forward - fully unpacking those expectations here would be a can of worms.

I will mention we are looking into ways for both Fenris and community developers to have proper strategic discussion on carbon as a whole. Please stay tuned