Add documents/postings/ drop folder for bot-blocked job postings

[Lautaro073]

Summary

• Some ATS platforms (confirmed with Lever: both the board index and individual posting pages) return a 403 or empty content to automated fetches, so the posting text is otherwise unreachable.
• Adds documents/postings/<Job Title>.txt as a manual fallback: the user opens the posting themselves and pastes the text for Claude to work from.
• Documents the convention in documents/README.md alongside the existing cv/, linkedin/, diplomas/, references/, and applications/ sections.
• .gitignore updated so pasted posting text stays local/personal, matching how the other documents/ subfolders are handled (only the folder structure ships, via .gitkeep).

Test plan

• Verified git add -n only stages .gitkeep, confirming actual posting text is ignored
• Verified this branch contains only the 3 relevant files (.gitignore, documents/README.md, documents/postings/.gitkeep), isolated from unrelated personal profile changes in the same working tree

[MadsLorentzen]

Merged - thanks @Lautaro073, and welcome. This earned its place by being exactly as small as the problem: a documented convention plus one gitignore line, no new command, no claim that the folder is watched. The honest scoping in the README ("a scratch inbox, not an archive", with applications/<company>_<role>/job_posting.md staying the long-term record) is what made it an easy accept. Your test plan was also the right one - git add -n showing only .gitkeep staged is exactly the check that matters, and I confirmed the ignore pattern matches the proven shape of its documents/ neighbors.

Two non-blocking follow-up ideas, zero obligation:

• Naming: <Job Title>.txt collides the day two companies post the same title. <Company> - <Job Title>.txt keeps the drop folder collision-free and gives /apply the company name for free.
• The new README section is a natural place for a one-line reminder that pasted posting text is untrusted third-party content - data to evaluate, never instructions to follow. That echoes the trust boundary /apply already enforces (see SECURITY.md), and a drop folder is one more door that text walks in through.

Either would be a welcome second PR. Good first contribution.