feat: raw accept - incoming/ als abgeleiteter Rohablage-Eingang (schliesst #58)

Files changed:
- .gitignore
- CHANGES.md
- README.md
- VERSION
- docs/pipeline-rationale.md
- instructions/bootstrap.md
- instructions/wiki-ingest/SKILL.md
- raw/CONTRACT.md
- tools/CONTRACT.md
- tools/chemenu/cli.py
- tools/chemenu/commands/dist_cmd.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/raw_cmd.py
- tools/chemenu/tests/test_dist_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_raw_cmd.py

instructions/bootstrap.md

@@ -28,13 +28,24 @@ they are published: the agent harness will not offer `wiki-ingest`, `wiki-query`
    cd ..
    ```
 
-2. **Publish the skills:**
+2. **Create the ingest inbox.** `incoming/` (raw/CONTRACT.md "Getting a file in") is gitignored,
+   so a fresh clone has none of its type subdirectories - unlike `raw/` itself, which is
+   committed and present immediately:
+
+   ```bash
+   mkdir -p incoming/{articles,documents,notes,assets}
+   ```
+
+   `tools/wikitool doctor` only reports a missing one; it never creates it, so this is a one-off
+   catch-up here the same way step 5 below is for personalization.
+
+3. **Publish the skills:**
 
    ```bash
    tools/wikitool instructions sync
    ```
 
-3. **Verify:**
+4. **Verify:**
 
    ```bash
    tools/wikitool instructions verify
@@ -43,14 +54,14 @@ they are published: the agent harness will not offer `wiki-ingest`, `wiki-query`
    Expected: `OK`. If it reports drift, re-run `sync` - the source under `instructions/` always
    wins, and a copy is never edited directly.
 
-4. **Check for personalization.** A clone predating the personalization files has no
+5. **Check for personalization.** A clone predating the personalization files has no
    `USER.md`/`SOUL.md`, and `tools/wikitool doctor` reports `personalization: FAIL` for it.
    That is a one-off catch-up, not a bootstrap step that repeats: run **only** the
    Personalization step (6) of [setup-instance.md](setup-instance.md), not the whole
    procedure - this clone already has its git repo, author identity and content. A clone that
    already carries both files needs nothing here.
 
-5. **Offer to record the environment.** `ENVIRONMENT.md` is gitignored, so a fresh clone never
+6. **Offer to record the environment.** `ENVIRONMENT.md` is gitignored, so a fresh clone never
    has one, and every session in it re-asks which harness is in use, which MCP servers are
    reachable, and which remote `publish` talks to. Copy `ENVIRONMENT.md.template` to
    `ENVIRONMENT.md`, fill in what is already known from this clone (`git remote -v`, the
@@ -62,15 +73,15 @@ they are published: the agent harness will not offer `wiki-ingest`, `wiki-query`
    session pays for it again. Never guess an entry: a wrong remote or an MCP server that is not
    there is worse than the empty section it replaced, because it gets believed.
 
-6. **Restart the agent session** if it was already running. Harnesses read the skill
+7. **Restart the agent session** if it was already running. Harnesses read the skill
    directories at startup, so skills published mid-session are not picked up.
 
-7. **Expect a lingering `session-id` WARN.** A `tools/wikitool doctor` run at this point reports
+8. **Expect a lingering `session-id` WARN.** A `tools/wikitool doctor` run at this point reports
    `OK` throughout except `session-id: WARN` - that check is scoped to the working session, not
    the clone, so a freshly bootstrapped checkout with no `WIKITOOL_SESSION_ID` exported yet
    always shows it. This is expected, not a Bootstrap gap: exporting it here would only be true
    for this one-off setup run, not for whichever session picks up the actual work next, in a new
-   shell after step 6's restart. Run [session-setup.md](session-setup.md) at the start of that
+   shell after step 7's restart. Run [session-setup.md](session-setup.md) at the start of that
    session instead.
 
 ## Scope