[samgbafa]

What

A new Policy/v3 registration (POST /policy/v3/policies) whose contentSource names encryptionKeyPath share/<shareId> now records that key on the owner's default network in the registration's own transaction. A publisher encrypts to the key's public key (served without authentication) and registers; it no longer needs a tinycloud.encryption/key.create grant or a create call before publishing.

• Authority: unchanged. Registration already requires the policy owner to hold decrypt on the exact key, as the network owner or through the owner's own delegations; a policy session is never that authority (owner_holds_capabilities).
• The key is written by EncryptionService::record_deterministic_key_in, which reuses the key.create path inside the registration transaction: network row lock, active network, per-network key limit. Only deterministic keys are recorded this way.
• A missing key is created at keyVersion 1, state active. At the key limit the registration answers 403 key_limit_exceeded and stores nothing (no registration, roots or key).
• An existing key is left as it is, whatever its state: a blocked key stays blocked. Clients that still create the key first keep working.
• The source's network must exist and be active (network_not_found 404, network_not_active 409).
• A registration the node already stores answers as before.

Docs: docs/encryption-named-keys.md. CHANGELOG updated.

Tests

New policy_v3/share_key_record_tests.rs (SQLite and PostgreSQL where marked):

• a delegate policy owner (decrypt through the space owner's grant) registers without any create; the key is recorded active at version 1 and the recipient's session decrypts;
• a recipient's policy session cannot register a policy over that key and no key is recorded;
• at the network key limit the registration is refused with key_limit_exceeded and stores neither the registration nor the key; a registration over an already recorded key still succeeds (both backends);
• a key created and blocked beforehand stays blocked, unchanged, through further registrations (both backends).

The Share decrypt fixture now encrypts to the public key without creating the key, so the existing TC-2192 share tests run on the recorded-key path. The unbound-source fixture creates the owner's default network.

Local: cargo fmt --check, cargo clippy -p tinycloud-node -p tinycloud-core --all-targets (-Dwarnings), cargo test -p tinycloud-node --lib 982 passed (PostgreSQL included).

Order

Clients stop creating the share key in a follow-up js-sdk change and a Share app change. Those must not be released before this node change is deployed.

Details: TC-2525