Nothing says the suite is only observed on Linux, and a macOS contributor unclaimed a working fix over it

> **Command corrected 2026-09-14 at `61b3a878`.** The first block printed the
> wrong field: with `grep -n` the line begins with the line number, so `$2` is
> the literal `runs-on:` and the pasted `ubuntu-latest` reproduces on no commit
> this repository has. My error when I filed it, and nothing has changed
> underneath. `$3` is the field, the answer is still a single value, and the
> second command still returns nothing:
>
> ```
> $ git rev-parse --short=8 HEAD
> 61b3a878
> $ grep -n 'runs-on' .github/workflows/ci.yml | awk '{print $3}' | sort -u
> ubuntu-latest
> $ grep -rni 'macos\|linux only\|linux-only' README.md CONTRIBUTING.md HACKING.md
> (nothing, exit 1)
> ```

Every job in `.github/workflows/ci.yml` is `runs-on: ubuntu-latest`, so the
workspace suite has only ever been observed on Linux. Nothing in `README.md`,
`CONTRIBUTING.md` or `HACKING.md` says so:

```
$ grep -n 'runs-on' .github/workflows/ci.yml | awk '{print $3}' | sort -u
ubuntu-latest
$ grep -rni 'macos\|linux only\|linux-only' README.md CONTRIBUTING.md HACKING.md
(nothing)
```

The daemon is `#[cfg(target_os = "linux")]` in the places that matter, and the
whole product is a Linux administration tool, so a macOS checkout failing parts
of the suite is expected. A contributor has no way to know that in advance.

## What it cost

On 2026-09-08 a contributor claimed #397, validated their fix locally, and
unclaimed it four minutes later:

> I'm unclaiming this after local validation: the focused regression test
> passes, but the repository's required daemon suite has 10 unrelated
> platform/global-state failures on macOS (874 passed).

Their focused test passed. They did the disciplined thing with the information
they had, which was a red suite and no document saying which reds are theirs.
That is a working contribution lost to a missing paragraph.

The research on this is not ambiguous: build environment is one of the
[top newcomer barriers](https://link.springer.com/chapter/10.1007/978-3-642-55128-4_21),
and it acts on everyone at once, including the people who never comment.

## Scope

- Say in `CONTRIBUTING.md` which platforms the suite is expected to pass on, and
that CI observes Linux only.
- Name the honest subset for a non-Linux checkout. `cargo test -p sysknife-types`
and `-p sysknife-core` are the obvious candidates, but the list should be
measured on a real macOS box rather than reasoned about from `#[cfg]` lines.
- Say what to do with a red daemon suite on macOS: which failures are structural
and how to tell them from a regression the contributor introduced.
- If a filter or a feature flag can express "the platform-independent subset",
that is better than prose, because prose about test selection goes stale in
exactly the way this repo keeps writing issues about.

## Difficulty

Easy, and it needs somebody on macOS to measure it rather than somebody on Linux
to guess. The measurement is the deliverable.

Read CONTRIBUTING.md, README.md, HACKING.md, and .github/workflows/ci.yml, then run the listed cargo test commands on a real macOS checkout. Measure the platform-independent subset and inspect the daemon-suite failures rather than inferring from cfg attributes. Done means the contributor guidance states CI's Linux coverage, the tested non-Linux subset, and how to interpret macOS failures.

Written by the indexing model from the issue text.