Fixes multiple memory safety bugs exposed by -fsanitize=address,undefined.

[leo-aa88]

Description

This PR fixes a series of memory safety bugs discovered after enabling AddressSanitizer and UBSan in the build (-fsanitize=address,undefined -fno-omit-frame-pointer -g). All bugs share a common root cause: raw char * strings being used without explicit length tracking, causing over-reads, invalid frees, and buffer overflows. The fix systematically replaces unsafe patterns with the existing String struct ({ char *data; size_t len; }).

---

Makefile Change

Added sanitizer flags to CFLAGS for development builds:

# Before
CFLAGS := -Wall -Wextra -Wpedantic -Werror -O2 -Wuninitialized

# After
CFLAGS := -Wall -Wextra -Wpedantic -Werror -O2 -Wuninitialized -fsanitize=address,undefined -fno-omit-frame-pointer -g

Note: $(STDROT_LIB) is compiled without sanitizer flags since it's a shared library loaded at runtime via dlopen. If ASan is added to the .so build it must match the main binary's runtime exactly.

---

Bugs Fixed

semantic_analyzer.c — safe_strdup called with len = MAX_BUFFER_LEN on string literals**

add_semantic_error constructed a String with .len = MAX_BUFFER_LEN regardless of actual message length, causing safe_strdup to memcpy 512 bytes off the end of short string literals into adjacent global memory. Fixed by changing add_semantic_error to accept a String parameter with correct length. Call sites using snprintf now capture the return value as the length. Bare string literal call sites use the new STRING_LITERAL(s) macro (sizeof(s) - 1).

---

New Macro Added (string_value.h)

#define STRING_LITERAL(s) ((String){ .data = (s), .len = sizeof(s) - 1 })

Safely wraps compile-time string literals into String structs with exact length computed at compile time — no strlen, no runtime cost.

Related Issue

Fixes #162

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Performance improvement
• Refactor

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have documented my changes in the code or documentation
• I have added tests that prove my changes work (if applicable)
• I have run the unit tests locally
• I have run the valgrind memory tests locally
• All new and existing tests pass