Bug: implicit namespace resolution in apply-time-mutation causes dependency sorting failure

Resources:
- namespace test
- pod-a
- implicit dep: namespace test
- pob-b
- implicit dep: namespace test
- explicit dep: apply-time mutation with pod-a as source

Output (from kpt using cli-utils master):
```
$ kpt live apply
namespace/test unchanged
1 resource(s) applied. 0 created, 1 unchanged, 0 configured, 0 failed
pod/pod-a created
pod/pod-b apply failed: failed to mutate "test_pod-b__Pod" with "ApplyTimeMutator": failed to read field ($.status.podIP) from source resource (/namespaces/test/Pod/pod-a): expected 1 match, but found 0)
2 resource(s) applied. 1 created, 0 unchanged, 0 configured, 1 failed
error: 1 resources failed
```

Problem:
- pod-b didn't get sorted into a 3rd ApplyTask. So when it applied, pod-a wasn't reconciled yet.

Start by reproducing the namespace, pod-a, and pod-b scenario with kpt live apply, then trace dependency sorting around ApplyTimeMutator and apply-time mutation sources. Done means pod-b is placed in a third ApplyTask after pod-a can reconcile, allowing the mutation to read pod-a's status successfully.

Written by the indexing model from the issue text.