security(storage): keep the repository signing key out of list() enumeration

[devitway]

The repository signing private key lives at <storage.path>/.signing/nora.key and is persisted owner-only (0600). But StorageBackend::list() / list_with_meta() enumerated it as if it were an artifact — only the pin sidecar was excluded — so it was swept into every enumeration-based operation:

• backup wrote it into the tar at mode 0644 (widened from the on-disk 0600), and restore then left it 0644 on disk;
• migrate --to s3 copied it into the bucket as a plaintext object, with no owner-only protection;
• GC/retention walked it as an unreferenced artifact (able to delete the signing identity), and the browse UI listed it.

This excludes the .signing/ prefix from both backends' enumeration (local + object store), mirroring the existing pin-sidecar exclusion, through a single shared is_reserved_signing_key helper. The key is loaded through direct filesystem I/O, never through list(), so the exclusion has zero runtime impact; operators provision it out-of-band.

Tests

Regression guards that fail without the fix:

• list() no longer surfaces the key (storage::local::tests::list_excludes_signing_key);
• a backup tar no longer contains it (backup::tests::test_backup_omits_signing_key).

[github-actions]

🐳 Test image pushed: ghcr.io/getnora-io/nora:pr-965

docker pull ghcr.io/getnora-io/nora:pr-965
docker run --rm -p 4000:4000 ghcr.io/getnora-io/nora:pr-965

[github-actions]

🐳 Test image pushed: ghcr.io/getnora-io/nora:pr-965

docker pull ghcr.io/getnora-io/nora:pr-965
docker run --rm -p 4000:4000 ghcr.io/getnora-io/nora:pr-965