SMB Server Phase 2: VFS backend build fix + integration test

- Add VfsFile: Send supertrait for Mutex compatibility
- Fix SmbServerCommand: struct → Subcommand enum with Start variant
- Fix tracing_subscriber::init() → try_init() to avoid panic when
  logger already initialized
- Fix CLI subcommand name: smb-server → smb-start (flatten naming)
- Add #[command(name = "smb-start")] for CLI disambiguation
- Fix unused variable warnings (smb_fs.rs, smb_server_backend.rs)
- Remove unused VfsFile imports (webdav.rs, scp_handler.rs)
- Integration test: Docker smbclient verified (list, upload, read)

vendor/smb2/.claude/rules/docs-maintenance.md

@@ -0,0 +1,12 @@
+When modifying code in a directory that contains a `CLAUDE.md` file, check whether your changes affect the documented
+architecture, key decisions, or gotchas. If they do, update the `CLAUDE.md` to stay in sync. If you notice a `CLAUDE.md`
+missing in a directory where there should be one, add it. Skip this for trivial changes (bug fixes, formatting, small
+refactors that don't change the architecture).
+
+If something failed due to a wrong assumption, add a `Gotcha/Why` entry to the nearest `CLAUDE.md`.
+
+Add `Decision/Why` entries to the nearest colocated `CLAUDE.md` for key decisions. If the decision has rich evidence
+(benchmarks, detailed analysis), put the evidence in `docs/notes/` and link from the CLAUDE.md.
+
+When writing guides, see [this diff](https://github.com/vdavid/cmdr/commit/13ad8f3#diff-795210f) for the formatting
+standard. (Before: AI-written. After: matching our standards for conciseness and clarity.)

vendor/smb2/.claude/rules/git-conventions.md

@@ -0,0 +1,14 @@
+## Commit messages
+
+- Use conventional commit messages.
+- Title: Capture the IMPACT of the change, not the tech details. From the title, we need to understand WHY we did this,
+  what we ACHIEVED with the commit. Length-wise, aim for about 50 chars max.
+- Body: Use bullets primarily. No word wrap. Don't hard-wrap body lines at 72 chars or any other width. Let the
+  terminal/viewer wrap naturally. Enclose entities in ``. No co-author!
+
+## PRs
+
+- Use the PR title to summarize the changes in a casual/informal tone. Be information dense and concise.
+- In the desc., write a thorough, organized, but concise, often bulleted list of the changes. Use no headings.
+- At the bottom of the PR description, use a single "## Test plan" heading, in which, explain how the changes were
+  tested. Assume that the changes were also tested manually if it makes sense for the type of changes.