So there's a couple errors I can see in there: one which causes your issue here, and one that will cause another painful issue, unless you're lucky.

1. malloc(strlen(buffer + 1)); is not the same as malloc(strlen(buffer) + 1);. Your allocation is actually one byte shorter than your input string. This means your strcpy will copy a byte past the allocated buffer. Only bad things can come out of that, and they may not be noticeable at first.
2. The issue you're actually describing here requires maybe a bit better of an understanding of pointers. malloc is giving you back an address - call it 0x0001 - and promises to have at least the available size you requested. You promise to at some point free that address. That address is stored into line. strchr returns a different address - one later in the string, specifically. Your loop continuously advances line to that new address plus one. So, at the end, you've been given an address, 0x0001, and you're trying to free some other address - e.g. 0x10de. That's why you can't free; you're freeing something other than what you malloc'd. You need to hold onto the actual address returned by malloc in another variable, and free that address specifically.

For #1, I'd personally recommend taking a look at strdup instead of malloc + strcpy. It's identical functionally, so I invite you to wholly understand all three functions and understand when/why they're used, but when copying a string exactly, strdup is the way to go - and it removes the possibility of an errant + 1. As part of the understanding, understand that the result of strdup does still need to be given to free eventually.

As a general note, to provide maybe some clarity on "is it fine to not free strings" - strings don't really exist in C. That is, there's not some special thing that the system sees as a string. They're by convention - a string is a blob of non-'\0' bytes that ends with '\0'. malloc and free do not know or care what you did with the bytes you received, and whenever you see a man page say that it does something with a string (copy, search, etc.), you can confidently substitute string with "blob of non-nul bytes ending with a nul byte". "string" just sounds nicer, and by convention, that's what we know a "C string" to be.

Most linux distributions either include C man pages by default or add them in when you install dev tools. I’d be surprised if man strchr didn’t already come up with something for you.

If you’re going down this path, it’s worth recognizing the different meanings of the man sections - shell commands in section 1 means that e.g. man chown is going to show you shell instead of the C function you’ll see from man 2 chown. In the same vein, section 3 has library functions, which are sometimes more relevant for you than section 2’s syscalls.

It feels like your file may have been CRLF instead of just LF. strtok would eat an empty line if it was strictly delimited by the given delimiter. Removing empty tokens is part of its intentional behavior.

the strtok issue is, per the man page, that strtok returns only “non empty” tokens with your given delimiters.

Given only one delimiter, the strchr approach is likely what I'd use. understanding strchr (and the similar strstr) is a pretty useful thing to have anyway, so it’s a good time to learn it. strchr makes no modifications and isn’t aiming to make tokens for you. It is looking for the first instance of a given byte in a C string and, provided it found it, returning you a pointer to that byte. as such, if it returns you something other than NULL, you’ve got a pointer to a byte. assuming you’re fine with the function modifying the buffer, you can convert that byte to a nul byte (\0), then print buffer, then a new line. You then advance your buffer pointer to the byte past the now-nul byte. Continue until strchr returns NULL, which is your last line - assuming the buffer is nul-terminated

Edit: example, now that I've got a real keyboard:

void strchr_loop(char *buf) {
    char* p;
    while ((p = strchr(buf, '\n')) != NULL) {
        *p = '\0';
        printf("Line = %s\n", buf);
        buf = p + 1;
    }
    printf("Last line = %s\n", buf);
}

Simplest answer: it enables programmers on any variation of an OS to get code. If I’ve got a python requirements.txt, getting those requirements installed is the same on any system I’ve got an appropriate python version. The designers of the languages effectively deemed that an important goal and explicitly put in the effort to include package management, in at least most of your listed cases.

They don’t have an authentication code; just an identification code. You log in elsewhere and put in the code so Microsoft knows which device you actually want to log in on. Think e.g. logging into most streaming services on a Smart TV - get the code and take it to your phone, where you actually log in.