obfuscate/deobfuscate should guard against locked (encrypted) state

[baby-joel]

Problem

notes obfuscate and notes deobfuscate don't check whether git-crypt is unlocked before running. This creates two failure modes:

1. .manifest already exists but is encrypted (locked state)

The while IFS=$'\t' read loop reads binary garbage from the encrypted .manifest. The associative arrays fill with nonsense entries. git mv renames may still succeed (git doesn't care about content), but the resulting state is broken — the manifest mapping is corrupted.

2. No .manifest exists yet, repo is locked

obfuscate creates a fresh plaintext .manifest alongside encrypted (binary) note files. The manifest is correct in isolation, but the local state is inconsistent — plaintext metadata next to encrypted content. On next git add, git-crypt's clean filter would encrypt .manifest before it hits the object store, so the remote would be fine, but the local working tree is in a weird half-state.

Fix

Both obfuscate and deobfuscate should call require_unlocked (or equivalent) at the top, before doing any work. Fail early with a clear error:

Error: git-crypt is locked. Run 'notes unlock' first.

The rudi status or git-crypt status command can detect this. The existing require_initialized pattern in lib/common.sh is a good model.

[junior-ricon]

Fixed by the expanded #195 and released in v0.9.1.

notes obfuscate and notes deobfuscate now use the shared readable-state guard and fail before mutating a locked repository.