fix(ext/shared): correct AttachmentCaps field names to match Rust core

The previous commit (f963ae3) used per_item_max_bytes and per_vault_*_max_bytes
which don't match the Rust core's struct (per_item_max_count and
per_vault_*_cap_bytes). Also fixes the per-item semantics: it's a COUNT of
attachments per item, not a byte sum.

Spec and plan docs updated in-place so future Task 7 cap-enforcement
implementation uses the correct names + semantics.

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

docs/superpowers/specs/2026-04-24-relicario-extension-1c-gamma1-design.md

@@ -193,9 +193,9 @@ The blob itself (`attachments/<id>.bin`) is written FIRST, so even if the item/m
 Caps live in `VaultSettings.attachment_caps` (β₂ shipped the schema; the UI is γ₂). γ₁ reads the four caps and enforces:
 
 - `per_attachment_max_bytes`: rejected at popup before sending to SW (cheap; fails fast)
-- `per_item_max_bytes`: sum of plaintext sizes of all attachments on the item; rejected at popup
-- `per_vault_soft_max_bytes`: sum of plaintext sizes across all items (computed from manifest summaries); shows warning toast but allows upload
-- `per_vault_hard_max_bytes`: same sum; hard reject at popup
+- `per_item_max_count`: count of attachments on the item (not bytes); rejected at popup
+- `per_vault_soft_cap_bytes`: sum of plaintext sizes across all items (computed from manifest summaries); shows warning toast but allows upload
+- `per_vault_hard_cap_bytes`: same sum; hard reject at popup
 
 If any cap is `undefined`, no limit is enforced for that level. γ₂ will surface the configuration UI; in γ₁ users without explicit caps get unlimited attachments (modulo the implementation's practical limits — large blobs work via Git Data API, but uploading a 50 MB file will be slow).