feat(quota): add per-app storage ceilings

An app's OWN store had no ceiling of any kind — only the group-SHARED
collections did, which is the inversion of what you'd expect. And
`authz::script_gate` returns `Ok(())` when there is no principal, so a
PUBLIC UNAUTHENTICATED route could reach `files::collection(..).create(..)`
and write blobs in a loop until the disk filled. `PICLOUD_FILES_MAX_FILE_SIZE_BYTES`
caps ONE file at 100 MB; nothing capped the count. Same for KV keys and docs
against Postgres.

Ceilings: `PICLOUD_APP_KV_MAX_ROWS` / `PICLOUD_APP_DOCS_MAX_ROWS` (100k) and
`PICLOUD_APP_FILES_MAX_TOTAL_BYTES` (10 GiB).

They are enforced DIFFERENTLY from the group ones, on purpose — porting the
group design as-is would have been a serious regression:

  * KV/docs check a ROW count, on INSERT only, with NO lock. `kv::set` is the
    hottest write path in the system; taking a per-app advisory lock on every
    set would serialize an app's entire data plane, and a `SUM(...)` scan would
    make write cost grow with the app's stored size. What the lock buys is
    small — unlocked overshoot is bounded by write concurrency (32) against a
    ceiling of 100k, ~0.03%. These are anti-DoS rails, not billing. An update
    adds no row and is bounded by the per-value cap, so it pays nothing at all.
  * No per-app BYTE ceiling for KV/docs: every value is already capped at
    `PICLOUD_KV_MAX_VALUE_BYTES`, so `max_rows x max_value_bytes` is ALREADY a
    finite bound. A second scan would buy nothing.
  * FILES are the exception and DO lock + sum: one blob may be 100 MB, so 32
    racing uploads could overshoot by gigabytes of real disk, and a file write
    is heavy enough that the lock and the SUM are lost in the noise. Checked on
    create AND update — an update that skipped the ceiling would be a free
    bypass (the same bug just fixed for group files: grow a 1-byte file to
    100 MB, repeat).

`group_quota` is renamed `quota`: it now serves both owners, and the module
doc is where the two enforcement strategies are contrasted.

Pinned by tests/atomic_write.rs: the key ceiling refuses a new key while
still allowing an update at the ceiling (rejecting updates would brick an app
the moment it filled up — worse than the DoS the rail exists to stop), and 10
concurrent uploads cannot exceed the disk ceiling, nor can an update grow past it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/picloud/src/lib.rs

@@ -180,7 +180,10 @@ pub async fn build_app(
             events.clone(),
             picloud_manager_core::kv_service::kv_max_value_bytes_from_env(),
         )
-        .with_atomic_writes(pool.clone()),
+        .with_atomic_writes(
+            pool.clone(),
+            picloud_manager_core::quota::app_kv_max_rows_from_env(),
+        ),
     );
     // §11.6 shared group collections (KV): a separate store keyed by the owning
     // group, resolved from cx.app_id's chain. Reuses the KV value-size cap.
@@ -219,7 +222,10 @@ pub async fn build_app(
             events.clone(),
             picloud_manager_core::docs_service::docs_max_value_bytes_from_env(),
         )
-        .with_atomic_writes(pool.clone()),
+        .with_atomic_writes(
+            pool.clone(),
+            picloud_manager_core::quota::app_docs_max_rows_from_env(),
+        ),
     );
     let dl_service: Arc<dyn DeadLetterService> = Arc::new(PostgresDeadLetterService::new(
         dl_repo.clone(),
@@ -255,7 +261,12 @@ pub async fn build_app(
             files_max_size,
         )
         // Metadata row + trigger fan-out in one tx; a rollback unlinks the blob.
-        .with_atomic_writes(pool.clone(), files_root.clone()),
+        // The per-app disk ceiling is enforced here too (advisory-locked).
+        .with_atomic_writes(
+            pool.clone(),
+            files_root.clone(),
+            picloud_manager_core::quota::app_files_max_total_bytes_from_env(),
+        ),
     );
     // §11.6 shared group collections (files): group-keyed blobs under
     // `<root>/files/groups/<group_id>/...`, resolved from cx.app_id's chain.