Stage 1/3: Extract gemma-cli shared tool core (tools+guards+auth+Tool), gemma-cli consumes it

[JoshuaVSherman]

Part of #73 (see it for full inventory, architecture, and rationale).

Stage 1 of 3 — Extract the shared tool core (pure refactor)

Lift gemma-cli's reusable, model-agnostic pieces into a standalone package so multiple frontends can consume them. No new behavior — this stage only relocates code and re-points gemma-cli at it.

What to extract (from web-jam-tools/gemma-cli/gemma_cli/)

• All 17 tools in tools/*.py (drive ×8, calendar ×2, gmail ×2, templates ×1, venue_contacts ×3, memory ×1).
• guards.py (file-discipline + protected-file policy).
• auth.py (Google OAuth credential loading).
• The Tool descriptor dataclass (currently in llm.py — it's a generic function-schema container, not Ollama-specific; move it to the core).

What stays in gemma-cli (the fallback)

• llm.py Ollama chat loop + all guard-rails (inline-JSON detection, loop guards, leaked-token aborts, etc.).
• cli.py REPL / system prompt / dispatch.

The change

• Create a new standalone package (e.g. webjam-tools-core) holding the extracted modules.
• Re-point gemma-cli to import the tools/guards/auth/Tool from the core (dependency inversion — gemma-cli becomes a consumer, not the owner). No duplicate definitions.

Acceptance criteria

• Core package contains all 17 tools + guards + auth + Tool, with no Ollama/gemma coupling.
• gemma-cli imports them from the core; zero duplicated tool code.
• Gemma behaves identically to before — same tools, same guard-rail behavior (regression check on the fallback path).
• Existing gemma-cli tests pass.

PR closing keyword: Closes #<this issue> only (this is its own complete unit). Parent epic #73 closes with Stage 3.