* fix(snap): stage JUJU_DATA at startup to avoid manual store review

1.0.1 declared a `personal-files` plug (`dot-local-share-juju`) so the
bundled juju could write to `~/.local/share/juju`. That interface is in
the snap-store's super-privileged set and pushes every release into the
manual review queue until an auto-connect declaration is granted per
plug, per snap — exactly the friction we wanted to avoid.

Drop the `personal-files` plug, revert to the auto-connecting
`juju-client-observe` (read-only), and introduce a startup hook in
`borescope.snap.stage_juju_data` that copies the host's read-only
`~/.local/share/juju` view into `$SNAP_USER_COMMON/juju` on every
borescope invocation. The snap's `JUJU_DATA` env var points at the
copy, so the bundled juju writes cookies/macaroons freely without
needing write access to the host directory.

Trade-offs (documented in README + tutorial + CHANGELOG):

- `juju login` / `juju switch` done inside a borescope session don't
  propagate back to the host JUJU_DATA. Run them with the host's juju.
- Macaroon refreshes inside borescope are session-local.

Plan to drop the staging once we have an auto-connect declaration:
see #31.

Bump version to 1.0.2.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* chore: enforce uv.lock <-> pyproject.toml sync in CI and pre-commit

The 1.0.1 PR bumped pyproject.toml but missed the matching uv.lock
update — the lockfile pinned borescope=1.0.0 while pyproject said 1.0.1.
No user impact (hatchling reads pyproject.toml, not uv.lock) but it
leaves the lockfile stale and noisy on every uv-touching command.

Add `uv lock --check` to:

- The lint job in CI, so any future version-bump PR that forgets the
  lockfile fails the gate.
- A new pre-commit hook scoped to pyproject.toml and uv.lock edits, so
  developers catch the drift before push.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>