To pick up neo@bc3b5ec3

This is necessarry because previously both ΔFtail.BlkRevAt and
ΔBtail.GetAt required zfile/root checkouts from @head. However during
update process in wcfs it is ΔFtail that is updated first, and only
after some invalidations zconn is resynced to new @head. And if we
move zconn.resync to happen before ΔFtail.Update, that would break
the invariant that data in OS cache correspond to zconn.At.

The rework triggered and clarified logic of what ΔBtail.GetAt
responsibility and functionality should be. Now it computes query result
only based on ΔBtail data, and returns valueExact=false or
revExact=false, if those data is insufficient. Previously it was further
trying to load data from the database which is conflicting with

	// ΔBtail semantically consists of
	//
	//	[]δB			; rev ∈ (tail, head]

Now that database access moved to GetAt user - to ΔFtail.BlkRevAt.

WCFS tests - that were broken after ΔFtail rework - now finally pass again.

* t2+qoldhead:
  .
  .
  .
  .
  .
  .
  .
  .

Unfortunately I could not avoid computing diff for ZBigFile objects
themselves, because after recent ΔFtail and ΔZtail fixes, wcfs tests
started to fail becase in the following scenario

    δFtail is created                        @at0
    file is created                          @at1
    file starts to be tracked when δFtail is @at2
    δFtail query is made about file block -> boom reports @at0, because the file does not exist there at all

To fix this ΔFtail now detects when ZBigFile objects are changed
themselves and indicate such a change with specifal δf with
δf.Epoch=true .

* t2+δfepoch: (38 commits)
  X ΔFtail: Rebuild vδE after first track
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  .
  ...

This is needed to detect where the file was created and indicate with
δF.Epoch=true correspondingly.