docs: define context workspaces and access modes

[moonlight16]

Summary

Expand the canonical Context Service concept documentation in response to CLI
review feedback.

• define a workspace in user-facing filesystem terms
• explain the current PVC implementation without assuming Kubernetes storage
  familiarity
• distinguish ReadWriteOnce from ReadWriteMany and explain --shared
• clarify that RWO is neither one-Pod exclusivity nor a security boundary
• document storage-class and CSI-driver responsibilities
• state honestly that usage reporting and deletion warnings are not implemented
  yet, including the limited protection Kubernetes provides for mounted PVCs

This is the primary conceptual documentation referenced by
rossoctl/rossoctl-cli#73.

Validation

• git diff --check
• documentation-only change

[cwiklik]

Summary

Docs-only expansion of docs/concepts/context-service.md — defines workspaces in filesystem terms, explains the PVC implementation, and maps CLI default/--shared to ReadWriteOnce/ReadWriteMany.

I checked the storage semantics and they're accurate:

• RWO framed as "writable from Pods on one cluster node at a time," explicitly not one-Pod exclusivity and not a security boundary — correct (that's the RWO/node-scoped vs ReadWriteOncePod distinction, and multiple pods on the same node can indeed share an RWO volume).
• RWX correctly noted as requiring a CSI driver that supports it.
• The PVC-protection finalizer keeping a volume in Terminating while a Pod still mounts it is accurate, and nicely framed as "a safety net, not a substitute for user-facing dependency checks."

Also appreciate the honesty about what isn't built yet (usage reporting, safe-deletion prompts) with a follow-up issue link, rather than implying it works. CI is green (Markdown Lint + Link Check included), DCO signed, no .claude//.vscode/ changes.

Approving.

Author: moonlight16 (MEMBER — maintainer)
Areas reviewed: Docs, storage-semantics accuracy (RWO/RWX/PVC protection)
CI: all green.