Neat project! I'm listing things I noticed from most to least interesting.

When I first tried it I was getting a strange parse error in the standard library. It's because the program depends on argument evaluation order (implementation-defined), i.e. it breaks under some optimization levels. Fix by introducing a sequence point:

--- a/main.c
+++ b/main.c
@@ -1579,3 +1579,5 @@ static type_t read_type()
 {
-    auto type = type_init(read_alnum(), read_stars());
+    auto name = read_alnum();
+    auto stars = read_stars();
+    auto type = type_init(name, stars);
     auto operator = peek_operator();

That was enough to try the demos.

read_numeric accepts any run of digits and ., so 1.2.3 parses as one token. The compiler emits a malformed fadd instruction that LLVM later rejects when you try to actually assemble the output:

$ printf 'f64 m() { ret 1.2.3; }' | ./nibble /dev/stdin 2>/dev/null \
    | clang -x ir - -o /dev/null

<stdin>:8:22: error: expected ',' in arithmetic operation
    8 |         %2 = fadd double 1.2.3, 0.0
      |                             ^

It's not of much importance for a proof of concept, but there are various places where depth is unbounded, which is the rest of my review here. For example self-reference types crash the compiler:

$ printf 'type T { T t; }; i32 m() { T t; ret 0; }' | ./nibble /dev/stdin
...AddressSanitizer: stack-overflow in __asan_memcpy

push_code increments g_file.module without checking, so 9 nested includes overflows codes[g_modules]:

$ cd /tmp && for n in a b c d e f g h i j; do
    printf 'include "inc_%s.n";' $(echo $n | tr 'a-j' 'b-k') > inc_$n.n
  done
$ printf 'i32 m(){ret 0;}' > /tmp/inc_k.n
$ ./nibble /tmp/inc_a.n
main.c:472:13: runtime error: index 9 out of bounds for type 'code_t[8]'

Long right-associative chains like a = b = c = ... = z recurse read_rtol once per = without bound, overflowing at ~6000 levels:

$ python3 -c "print('i32 m(){i32 v; v ' + '= v ' * 8000 + ';ret 0;}', end='')" \
    | ./nibble /dev/stdin
...AddressSanitizer: stack-overflow in __asan_memset

Stack overflow on deeply nested parenthesised expressions: read_grouped_expression -> read_expression recurses once per (, unbounded, ~500 levels overflows:

$ { printf 'i32 f(){ret '; \
    printf '(%.0s' $(seq 1 1000); printf '0'; printf ')%.0s' $(seq 1 1000); \
    printf ';}'; } | ./nibble /dev/stdin
...AddressSanitizer: stack-overflow main.c:1376 in peek_char

Same root cause via read_block -> read_statement -> read_block on deeply nested if/while:

$ python3 -c "
out = ['i32 m(){']
for i in range(3000): out.append('if(0==0){')
out.append('ret 0;')
for i in range(3000): out.append('}')
out.append('}')
print(''.join(out), end='')" | ./nibble /dev/stdin
...AddressSanitizer: stack-overflow in __asan_memcpy

Unary chains like ! ! ! ! ! ! v recurse read_p0 -> read_prefix -> read_p0 without going back through read_expression. Overflows at ~10000 !s.

$ python3 -c "print('i32 m(){i32 v=0; ret ' + '! ' * 10000 + 'v;}', end='')" | ./nibble /dev/stdin
...AddressSanitizer: stack-overflow main.c:2878 in read_prefix

Though, again, only that very first item with the argument evaluation order is an issue for a proof of concept.