feat: mount corestore volumes

readme.md

@@ -134,11 +134,29 @@ After connection, Coreflow authenticates with `JUMPCODE` and requests a stateful
 Coreflow depends on these Cloudly-side resources being present and valid:
 
 - Cluster configuration for the authenticated identity.
-- Service records with image, resource, domain, port, and secret bundle references.
+- Service records with image, volume, resource, domain, port, and secret bundle references.
 - Image records pointing either to internal Cloudly image storage or an external registry.
 - Secret bundles that can be flattened into environment key/value data.
 - SSL certificates for all routed domains.
 
+## Corestore Volumes
+
+Coreflow deploys `corestore` as a global base service and bind mounts `/run/docker/plugins` so Docker can discover the `corestore` VolumeDriver socket on each node.
+
+Workload services can declare first-class volumes:
+
+```ts
+volumes: [
+  {
+    mountPath: '/data',
+    driver: 'corestore',
+    backup: true,
+  },
+]
+```
+
+If `name` is omitted, Coreflow derives a stable Docker volume name from the service id and mount path. During service creation it sends a Docker volume mount with `DriverConfig.Name = 'corestore'`, plus service metadata as driver options and volume labels.
+
 ## Coretraffic Integration
 
 Coreflow starts an internal SmartServe/TypedSocket server on port `3000`. Coretraffic is expected to connect to that server and tag its connection as `coretraffic`.
@@ -190,7 +208,7 @@ Project layout:
 - Reconciliation removes and recreates services when the Docker service reports that it needs an update.
 - Workload services must be attached to `sznwebgateway` for routing to be generated.
 - The current routing logic uses the first available container IP for a service.
-- `PlatformManager` currently provides lifecycle hooks but does not reconcile platform services yet.
+- `PlatformManager` provisions `database` and `objectstorage` bindings through corestore.
 
 ## License and Legal Information