docs(ax): UNKNOWN mergeability is a fifth row, and its decoder is the same query

[lilyshen0722]

@sprint-review, verifying #1122 (OPEN, 10/10 green, MERGEABLE/CLEAN), noticed it settled only on the second query — the first returned UNKNOWN/UNKNOWN. That is GitHub computing mergeability lazily on read, not a state change.

Adds it as a fifth row to the "value correct and insufficient" table in entry 12:

surface	the value	what it can mean
mergeable / mergeStateStatus	UNKNOWN	not mergeable — or not computed yet

Why it needs a paragraph and not just a row

It inverts the rule that table earns. The other four are disambiguated by a different surface — a write site, a second file, branch protection. This one is disambiguated by the same query, run again: the first read can return UNKNOWN and schedule the computation the second read collects. So UNKNOWN → MERGEABLE/CLEAN across two identical calls is not a transition, and anyone reading that field to decide whether to press must read it twice.

Stated with its limit

Two independent observations (a stale-PR matrix where the PRs most likely to be DIRTY came back null on a one-shot pass; and @sprint-review on #1122). Not reproduced on demand — re-running it today across #1122, #1140, #1156, #1204 and #809 returned the settled value on the first read every time, because all five had been queried earlier in this session and were already warm. The entry says so rather than implying a clean repro.

That limit is itself the point: the failure only appears cold, which is exactly the condition a one-shot matrix runs under.

Docs-only.

🤖 Generated with Claude Code

[lilyshen0722]

Closing as a duplicate of my own #1213, which I failed to check for before opening this.

#1213 covers the same finding earlier (07:26Z vs 09:29Z) and better: it has the reproduction I could not get today — gh pr view 942 returning UNKNOWN/UNKNOWN then BLOCKED/MERGEABLE on two identical calls, isolated on a PR deep enough in the backlog to still be cold — plus the ten-PR natural experiment on the open list.

It also contradicts what this PR proposed, correctly. I added UNKNOWN as a fifth row to entry 12's "correct and insufficient" table. #1213 argues it does not belong there: the other four say something true and need a second surface to finish the sentence, whereas UNKNOWN says nothing about the object at all, so there is no second surface to go find and no missing-query feeling to prompt the search. That is the sharper claim and it makes this PR's framing wrong, not merely redundant.

Nothing here is worth folding in. The one thing this PR had that #1213 does not — that five PRs re-read today all returned the settled value on the first read because they were warm — is already implied by #1213's mechanism and is weaker evidence than its actual repro.