chore: use $DOC_ROOT for the requests path and drop the consumer-project reference

[poxet]

Documentation-only cleanup of .claude/mission.md, completing the ecosystem-wide pass across all 16 Tharga projects. The rules behind it live in shared-instructions.md → Feature Requests (cross-project) → External consumers.

Overlaps with #64 — read before merging

#64 already contains this same fix (commit a07297d, "use DOC_ROOT for requests path and drop the consumer-repo reference"), bundled with a version-line bump and comment cleanup.

This PR exists so Cache is covered on its own branch like every other project, and so the fix is not gated on the rest of #64. Whichever merges first wins:

• If chore: version line to 1.1, comment cleanup, and mission.md request sources #64 merges first, this PR becomes an empty diff — close it, no action needed.
• If this merges first, chore: version line to 1.1, comment cleanup, and mission.md request sources #64's .claude/mission.md hunk will conflict or no-op; drop that hunk from chore: version line to 1.1, comment cleanup, and mission.md request sources #64 and keep the rest.

Both make the same two edits, so there is no risk of them disagreeing about the outcome — only about which commit carries it.

The two changes

1. The requests path was a literal machine path.

- **Incoming requests**: `c:\Users\danie\SynologyDrive\Documents\Notes\Tharga\Requests.md`
+ **Incoming requests**: `$DOC_ROOT/Tharga/Requests.md`

A hard-coded path resolves on exactly one machine and silently finds nothing everywhere else — and "silently finds nothing" is indistinguishable from "there was nothing pending".

2. Removed the reference to a consuming product's checkout.

- **Eplicta requests**: `$DEV_ROOT/Eplicta/plan/requests.md` — check for requests from Eplicta on startup

A Tharga project should not know about a specific consuming product. The line made this project's startup depend on a checkout it has no claim to, and gave one consumer an inbound route nobody else could use.

The boundary now runs one way. A consuming product raises a GitHub issue on this repository — that is the whole inbound channel. Outbound is a comment on that issue and nothing further: no follow-up entry, no adoption tracker, no writing into their files. Whoever asked tracks their own adoption.

Nothing is lost: open GitHub issues are already a mandatory request source on every startup, independent of what mission.md lists.

Note on merging

Merging triggers the full CI pipeline including release, because no repo filters by path — so it publishes a new patch version identical in content to the current one. That cost applies once, whichever of the two PRs carries the change.