#418 Vault annotations: --note/--notes flag inconsistency and UX improvements

Follow-up improvements from swamp-club#412 review

Several non-blocking UX improvements were identified during the PR review for vault annotations. Grouping them here:

1. --note vs notes field name mismatch

The CLI flag is --note (singular) but the data model and vault inspect --json output uses notes (plural). Consider renaming the flag to --notes or accepting both.

2. vault annotate --json should include resulting annotation state

The JSON output after a successful annotate only returns { vaultName, secretKey, vaultType, fieldsUpdated, cleared, timestamp } — it doesn't include the updated annotation values. A script that wants to confirm what was stored must make a second call to vault inspect. Including the resulting annotation in the completed payload would make scripting more convenient.

3. --clear should warn or error when combined with --url/--note/--label

When --clear is used alongside --url/--note/--label, the other flags are silently discarded. Consider either validating mutual exclusivity or documenting the precedence in the help text.

4. No single-label deletion mechanism

VaultAnnotation.merge() merges labels additively. There is no way to remove a single label — only --clear removes all annotations at once. Consider adding --remove-label <key> support.

5. secretExists decrypts the full secret

Both annotate and inspect deps check secret existence by calling svc.get() which performs full AES-GCM decryption just to return a boolean. Using svc.list() and checking membership would be cheaper. This matches the pre-existing pattern in put.ts — a codebase-wide improvement opportunity.