Global MCP configuration: infer the workspace from the client working directory

## Summary

Today every repository/checkout needs its own MCP wiring. The README shows a per-project Claude Code config:

```json
{"mcpServers": {"rust-knowledge": {"command": "/knowledge-mcp", "args": ["--manifest-path", "/path/to/workspace/Cargo.toml"]}}}
```

and this repo's own (gitignored) `.mcp.json` hardcodes absolute paths to both the binary and the manifest. That means N repos × M checkouts × per-machine paths of duplicated config.

Requested: register the MCP server **once, globally** (Claude Code user scope: `claude mcp add --scope user rust-knowledge /knowledge-mcp`, or the user-scope entry in `~/.claude.json`), with **no per-repo arguments at all**. The server infers which workspace it serves from its working directory: Claude Code launches stdio MCP servers with cwd set to the project directory, so the nearest `Cargo.toml` ancestor of cwd identifies the workspace.

## What is requested

1. Make cwd-based inference the first-class mode for `knowledge-mcp`:
- No `--manifest-path` → resolve the workspace by walking up from cwd to the nearest `Cargo.toml` (cargo semantics: a workspace-member manifest still resolves to the right workspace via cargo metadata). Close whatever gaps exist on the *open-index* path: the index dir must default to the resolved workspace's `.rust-knowledge` even when cwd is a subdirectory.
- Explicit `--manifest-path` / `--index-dir` keep working (backward compat; also the override story for unusual clients).
2. Fail fast with an actionable message when inference cannot work:
- No `Cargo.toml` ancestor of cwd (client did not set cwd into a workspace): say exactly that, name the cwd, and show the fix (pass `--manifest-path` or launch from a workspace dir).
- Manifest found but no index: name the inferred workspace root and the expected index dir, and give the exact `rust-knowledge index` command to build it.
3. Log the inferred workspace root + index dir at startup (stderr; pairs with the tracing issue).
4. Document the global setup in the README: the user-scope registration for Claude Code (and the equivalent for Codex-style configs), a note that per-repo `.mcp.json` entries are no longer needed, the cwd contract clients must satisfy, and the still-supported explicit form.
5. Integration test: launch the server in the committed fixture workspace with **zero arguments** and exercise a search end-to-end via the rmcp client (the crate already has an rmcp client dev-dependency and `tests/mcp.rs` to model after). Also test both failure modes above (wrong cwd → clean error; workspace without index → clean error naming the fix).

## Why it matters

- One global registration replaces unbounded per-repo config duplication; absolute per-checkout paths break across machines and after moves.
- Agents jump between many repos and checkouts; the server should follow the client, not a pinned manifest.

## Potential issues and risks

- **The cwd assumption is client-specific**: Claude Code sets the server's cwd to the project dir; other clients may not. That is why explicit flags must remain supported and the no-workspace error must be excellent rather than a hang.
- Nearest-Cargo.toml-wins can pick a *member* manifest in nested-workspace layouts (a checkout containing multiple workspaces); cargo resolves the member to its workspace, which matches intent most of the time — document the semantics.
- Behavior change: users who relied on the server refusing to start without `--manifest-path` now get inference; README must make the new contract explicit. Existing per-repo `.mcp.json` setups keep working unchanged.
- Concurrent servers over one index dir (multiple sessions on the same repo): the open path must not take a tantivy writer lock (readers only); verify and pin with a cheap test if possible.
- Symlinked checkouts / monorepo roots: walk-up must behave sanely (canonicalize for logging only; do not break identity).

## Acceptance criteria

- `knowledge-mcp` with zero arguments works when cwd is inside any cargo workspace (proven by an integration test on the fixture).
- Explicit flags behave exactly as before.
- Both failure modes produce actionable errors (tested).
- README documents the one-time global registration and the cwd contract.

Read README and tests/mcp.rs first, then trace the knowledge-mcp startup and argument handling from the binary entry point. Run the existing MCP tests and inspect the committed fixture workspace. Done means zero-argument search works there, explicit flags remain supported, both cwd/index failures are actionable, startup logs the resolved paths, and global setup is documented.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.