[Possible Bug] sparse-checkout disable followed by re-init

[<rsbecker@nexbridge.com>]

Hi All,

I noticed a change at 2.35.1 regarding sparse-checkout and am wondering
whether I am just missing something:

1. Create upstream.
2. Clone with --no-checkout --depth=1 --filter=blob:none
3. sparse-checkout init
4. sparse-checkout set, with a pattern
5. sparse-checkout list
6. checkout master
7. sparse-checkout reapply
8. sparse-checkout add (up to here, everything is fine, the working area is
consistent with the sparsity patterns)
9. sparse-checkout disable (the disable works - I think)
10. sparse-checkout list reports fatal: this worktree is not sparse, which
is new in 2.35.1. In 2.34.1, the sparse patterns are reported without error.
I think this is incorrect behaviour because the sparse patterns are still
configured.
Then I try to recover
11. sparse-checkout init (seems to work - no errors)
12. sparse-checkout list (correctly reports what was previously set/add)
13. sparse-checkout reapply (does nothing apparent - the objects that added
to the working area during the disable are still there. My assumption was
that the files not matching the sparsity patterns would be pruned).

The .git/config is:
[core]
        repositoryformatversion = 1
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = file:///home/randall/stuff/src.git
        fetch = +refs/heads/master:refs/remotes/origin/master
        promisor = true
        partialclonefilter = blob:none
[branch "master"]
        remote = origin
        merge = refs/heads/master
[extensions]
        worktreeConfig = true

My question is, from this point, is there a way to recover the sparsity of
the working index (which I expect), or do I have to clone again (not
desirable). This seems like a functional change. What is weird to me is that
I did not expect a worktreeConfig=true in this situation.

Thanks,
Randall