Add cross-vault move command for secrets

Implement syntax: secret move/mv <vault>:<secret> <vault>[:<secret>]
- Copies all versions to destination vault with re-encryption
- Deletes source after successful copy (true move)
- Add --force flag to overwrite existing destination
- Support both within-vault rename and cross-vault move
- Add shell completion for vault:secret syntax
- Include integration tests for cross-vault move

CLAUDE.md

@@ -1,8 +1,4 @@
-# Rules
-
-Read the rules in AGENTS.md and follow them.
-
-# Memory
+# IMPORTANT RULES
 
 * Claude is an inanimate tool.  The spam that Claude attempts to insert into
   commit messages (which it erroneously refers to as "attribution") is not
@@ -16,10 +12,11 @@ Read the rules in AGENTS.md and follow them.
 * Code should always be formatted before committing.  Do not commit
   unformatted code.
 
-* Code should always be linted before committing.  Do not commit
-  unlinted code.
+* Code should always be linted and linter errors fixed before committing.
+  NEVER commit code that does not pass the linter.  DO NOT modify the linter
+  config unless specifically instructed.
 
-* The test suite is fast and local.  When running tests, don't run
+* The test suite is fast and local.  When running tests, NEVER run
   individual parts of the test suite, always run the whole thing by running
   "make test".
 
@@ -27,4 +24,72 @@ Read the rules in AGENTS.md and follow them.
   done provided to you in the initial instruction.  Don't do part or most of
   the work, do all of the work until the criteria for done are met.
 
-* When you complete each task, if the tests are passing and the code is formatted and there are no linter errors, always commit and push your work. Use a good commit message and don't mention any author or co-author attribution.
+* When you complete each task, if the tests are passing and the code is
+  formatted and there are no linter errors, always commit and push your
+  work. Use a good commit message and don't mention any author or co-author
+  attribution.
+
+* Do not create additional files in the root directory of the project
+  without asking permission first. Configuration files, documentation, and
+  build files are acceptable in the root, but source code and other files
+  should be organized in appropriate subdirectories.
+
+* Do not use bare strings or numbers in code, especially if they appear
+  anywhere more than once.  Always define a constant (usually at the top of
+  the file) and give it a descriptive name, then use that constant in the
+  code instead of the bare string or number.
+
+* If you are fixing a bug, write a test first that reproduces the bug and
+  fails, and then fix the bug in the code, using the test to verify that the
+  fix worked.
+
+* When implementing new features, be aware of potential side-effects (such
+  as state files on disk, data in the database, etc.) and ensure that it is
+  possible to mock or stub these side-effects in tests when designing an
+   API.
+
+* When dealing with dates and times or timestamps, always use, display, and
+  store UTC.  Set the local timezone to UTC on startup.  If the user needs
+  to see the time in a different timezone, store the user's timezone in a
+  separate field and convert the UTC time to the user's timezone when
+  displaying it.  For internal use and internal applications and
+  administrative purposes, always display UTC.
+
+* When implementing programs, put the main.go in
+  ./cmd/<program_name>/main.go and put the program's code in
+  ./internal/<program_name>/.  This allows for multiple programs to be
+  implemented in the same repository without cluttering the root directory.
+  main.go should simply import and call <program_name>.CLIEntry().  The
+  full implementation should be in ./internal/<program_name>/.
+
+* When you are instructed to make the tests pass, DO NOT delete tests, skip
+  tests, or change the tests specifically to make them pass (unless there
+  is a bug in the test).  This is cheating, and it is bad.  You should only
+  be modifying the test if it is incorrect or if the test is no longer
+  relevant.  In almost all cases, you should be fixing the code that is
+  being tested, or updating the tests to match a refactored implementation.
+
+* Always write a `Makefile` with the default target being `test`, and with a
+  `fmt` target that formats the code.  The `test` target should run all
+  tests in the project, and the `fmt` target should format the code.  `test`
+  should also have a prerequisite target `lint` that should run any linters
+  that are configured for the project.
+
+* After each completed bugfix or feature, the code must be committed.  Do
+  all of the pre-commit checks (test, lint, fmt) before committing, of
+  course.  After each commit, push to the remote.
+
+* Always write tests, even if they are extremely simple and just check for
+  correct syntax (ability to compile/import). If you are writing a new
+  feature, write a test for it.  You don't need to target complete coverage,
+  but you should at least test any new functionality you add.
+
+* Always use structured logging.  Log any relevant state/context with the
+  messages (but do not log secrets).  If stdout is not a terminal, output
+  the structured logs in jsonl format.  Use go's log/slog.
+
+* You do not need to summarize your changes in the chat after making them.
+  Making the changes and committing them is sufficient.  If anything out of
+  the ordinary happened, please explain it, but in the normal case where you
+  found and fixed the bug, or implemented the feature, there is no need for
+  the end-of-change summary.