Fix append-file concatenating without a newline (#204)

[LNAMTY]

Description

Fixes #204. append-file is documented as appending a line ("a trailing newline is always added"), but it only adds the newline after the text, never before it. When the file does not already end with a newline — which is what the byte-exact write-file leaves behind — the appended line does not start on a new line and the content silently merges (eggs + cheese → eggscheese).

Adds line_separator/2 to skills.pl, which emits a newline before the append only when the file is not already at a line start. write-file is untouched and stays byte-exact, per @vsbogd's comment on the issue.

How Has This Been Tested?

• write-file "/tmp/s.txt" "milk, bread, eggs" then append-file "/tmp/s.txt" "cheese, apples" → milk, bread, eggs\ncheese, apples\n, the output the issue expects.
• A further append-file → no double blank line; append-file to an empty file → no leading blank line.
• write-file "/tmp/f.txt" "" → still 0 bytes, write-file "/tmp/f.txt" "Hello" → still Hello. write-file behaviour is unchanged, so test_create_file / test_create_empty_file are unaffected.

Checklist

• The code generated by LLM is reviewed by the PR creator
• Self-review completed
• Test scenarios above are passed with the version of the code from PR

[LNAMTY]

@MartinEbner reworked since #243's description was written — this no longer touches write-file, it stays exact-bytes, so the design conflict you flagged is gone. The fix now sits in append-file, which is documented to append a line but never guaranteed it starts on one.

Worth flagging: #243 as written does not fix #204 — its append_file only adds a trailing newline, so write-file "milk, bread, eggs" then append-file "cheese, apples" still lands eggscheese on disk (the read-back makes it visible, not prevented). The two are complementary; happy to port this into fileio.py if #243 lands first.

@vsbogd ready for review.

[MartinEbner]

Thanks for the ping — agreed on both counts. #243 doesn't claim to fix #204: its append_file keeps the existing trailing-newline-only contract, so your eggscheese case still lands on disk (the read-back makes it visible in the result, it doesn't prevent it). And with write-file staying exact-bytes here, the design conflict flagged in #243's description is gone — I've updated that description to match the rework.

The two compose cleanly, and whichever lands second does the small port. If this one lands first, #243 picks up the line-start guard in fileio.append_file at rebase (read the last byte, prepend the newline when missing — the verified result then covers it); if #243 lands first, happy to take you up on the fileio.py port. Either way the overlap is a few lines of skills.metta.