Clarify in protocol guide when the cob commit graph is disjoint — radicle.xyz

and add more information for clarity how local storage works

refine section on local storage

correct when the cob commit graph is disjoint

 is stored within the same repository using Git [namespaces][gns], where Node
 IDs are used as the namespace. This allows storage to be managed through a
 partitioned approach where each user maintains their own *local fork* of a
 repository, as well as any other forks they have an interest in, all within the
 same Git repository. These forks are then shared among users across the
 network.
 repository, as well as forks of other users they have an interest in, all
 within the same Git repository. These copies are then shared among users
 across the network.
 Each repository fork has a *single owner and writer*, and users are only
 permitted to make changes to their respective forks.
 Each repository fork has a *sole owner and writer* identified by their
 Node ID and users are only permitted to make changes to their respective fork.
 ### Working vs. Stored Copy

 To achieve this, Radicle makes use of Git's native synchronization primitives,
 and encodes COBs as a set of commits in a [directed acyclic graph][dag] (DAG).
 Each issue, patch or identity document is represented by one such commit graph
 that is disjoint from any other COB or source code branch.
 The identity document is represented by one such commit graph that is disjoint
 from any other COB or source code branch, while issues are represented as a graph
 pointing to the identity document graph, and patches a graph pointing to both
 the identity document OID and the source code commits the patch is for.
 This representation gives Radicle a few things for free: