### Please describe the problem.
10.20220525 forcefully untrusts `exporttree=yes`, causing `fsck` to unconditionally fail when probing for a key that only exists on such a remote.

The full story is at https://github.com/datalad/datalad-next/issues/72

The summary is that an application needs to know whether a particular key is on such a remote, and it can only be on that remote (there is no other). Because the availability info from `whereis` cannot be trusted (same rational as the one causing the change in git-annex implementation) it uses `annex fsck --fast --key -f ...` which now fails.

Parsing the JSON output of the failing `fsck` call seems to be the only way left to accomplish this goal.

```
% git -C myclone/.git/dl-repoannex/origin/repoannex -c diff.ignoreSubmodules=none annex fsck -f origin --fast --key XDLRA--refs -c annex.dotfiles=true --json
  Only these untrusted locations may have copies of XDLRA--refs
        d8735795-663e-4702-8f7e-8c684264a9df -- [origin]
  Back it up to trusted locations with git-annex copy.
{"dead":[],"command":"fsck","note":"(Avoid this check by running: git annex dead --key )","success":false,"input":[],"untrusted":[{"here":false,"uuid":"d8735795-663e-4702-8f7e-8c684264a9df","description":"[origin]"}],"key":"XDLRA--refs","error-messages":[],"file":null}
fsck: 1 failed
```

That however, is substantially more complex than looking at the exit code -- given that the entire call is about a single key.

### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

99.9% are just splendid. Wondering here whether this particular consequence of the change was intentional and avoidable?


> [[notabug|done]] --[[Joey]]
