It seems that this kind of corruption can propagate between clones as well. Sadness.

Ouch, that's unfortunate. Can this be easily checked during an addgroup?

Maybe the server could reject such changes, but I'd rather simply roll clients with the fix.

Separately, it's not exactly the kind of corruption from the test that can propagate, because push would fail in the example of the test.
But if the filelog exists (or presumably, is created afterwards), then the push can succeed. And then hg status when wdir is at such a revision in a non-narrow clone would always report the empty file as being modified.

I doubt someone else cares, but just in case, one can find problematic revisions with this command:

@command(
    b'zzz',
    [
        (b'r', b'rev', b'', _(b'revision to display'), _(b'REV')),
    ],
    intents={INTENT_READONLY},
)
def zzz(ui, repo, **opts):
    """"""
    opts = pycompat.byteskwargs(opts)
    repo = repo.unfiltered()
    revs = scmutil.revrange(repo, [opts.get(b'rev')])
    for r in revs:
        node = repo[r].node()
        mnode = repo[r].manifestnode()
        for (f, fnode) in repo.manifestlog[mnode].readdelta().iteritems():
            if fnode == repo.nullid:
                ui.write(b'%b %b\n' % (hex(node), f))