Like @TheBobkin mentioned, in a 3-node vSAN cluster there is no dedicated witness node like we would see in a 2-node cluster. The witness role "floats" between the hosts as needed, but when you look at the virtual objects, you will see the Witness piece of your components, which is just a small component and doesn't take a lot of space, it's just metadata.
With your design, two disk groups with 4 1TB capacity disks, with a FTT1, should have something like 12TB total usable for the cluster. Also, I would look at the 960GB high endurance disks for the cache, only 800GB of cache can be used per disk group, so the extra capacity is for wear of the disk. As SSD's are used and wear, the cells become unusable which results in reduction of capacity.
So all 3 hosts will contain data, and with FTT1 it will be mirrored, so each object will have two copies. So, with FTT1 and SW1, and a disk size of < 255GB, you will have your object that represents your VMDK on a diskgroup on one node, and a copy of that component on a disk group on a different node. In this scenario, if you lost a node, and of the components would be rebuilt on the remaining two nodes from the mirrored sets. The thing to watch for is that you plan on the ability to loose a node, so plan your storage max as 66% of the total available, and the compute max also as 66% of normal. In your case, I would not provision more than 7TB of data, which is ~58% of your total, as you will need some unused space for rebuilds, snapshots, etc. This will ensure you can do maintenance on the cluster without issue, and that you can loose a host and not be in a degraded state, but continue to operate normally.
Once you repair a failed node, or introduce a new node, the storage policy will continue to take effect, and some components will move to the new node as appropriate.
Quick example, simple VM with a single, 100GB VMDK. There's 3 objects that make up the VM; the VMDK itself, the VM Home (config files and such), and the VM swap object. The VM itself is executing from node2.
The VMDK object has a RAID-1 tree established between node2 and node1, meaning there's a component on node2 and the copy of that component on node1, and the RAID-1 tree mirrors the writes to both components, over the network, just like normal RAID-1 would do. The Witness component, remember, just metadata, is on node3.
The VM Home object is the same as the VMDK object in this case. The VM swap object on the other hand is slightly different. The RAID-1 tree is between node2 and node3, with the Witness component being on node1.
So in this example, loosing node1, a new component for the VMDK object and VM home object will have to be created on node3, and the Wintess components will remain on node3. The Witness component for the VM swap object will need to be re-created on either node2 or node3. Once I get node1 back in service, the cluster will rebalance itself to ensure that everything's spread back out again.
If you wanted to instead go with a 2-node cluster using a Shared Witness, remember that the Shared Witness CANNOT run on the 2-node cluster it is servicing, and the Shared Witness is best as a Virtual Appliance, not an expensive piece of hardware. Also, with a 2-node cluster, the 66% estimates I provided above, they now become 50%, so you will loose 50% of your capacity instead of 33% using a 2-node cluster.
