Add calendar/address-book sharing backend

Introduce internal/db, a small SQLite-backed store (pure-Go
modernc.org/sqlite, no CGO) at <data_dir>/nidus.db holding
calendar_shares and addressbook_shares grant tables (owner, resource
name, shared-with user, read/write permission). This is the first step
towards user management and a web UI: a real datastore that a future
admin CLI/UI can build on, instead of the static config.yaml.

Wire sharing into the CalDAV/CardDAV backends:
- ListCalendars/ListAddressBooks now also include resources shared with
  the requesting user, exposed under the synthetic local name
  "<owner>~<name>" in the grantee's own home-set — no separate account,
  no data copying, the object still physically lives under the owner's
  store.Store namespace.
- All read paths (Get/List/QueryCalendarObjects, address book
  equivalents) resolve the synthetic name back to (owner, real name) and
  require any share (read or write) to exist.
- All write paths (Put/Delete object, DeleteCalendar/AddressBook)
  additionally require a write-permission share; read-only shares get a
  403 Forbidden.
- CreateCalendar/CreateAddressBook remain scoped to the acting user's own
  namespace — sharing an existing collection is done via ShareCalendar/
  ShareAddressBook, not by creating one directly in someone else's name.

Add internal/db/shares_test.go (grant/lookup/update/unshare/list
semantics) and internal/{caldav,carddav}/backend_test.go (shared
calendar/address book visibility, write permission enforcement,
unauthorized access rejection). Update README (features, new "Sharing
calendars and address books" section, project layout, dependencies) and
copilot-instructions.md to document the new package and sharing model.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

.github/copilot-instructions.md

@@ -1,7 +1,9 @@
 # Copilot Instructions for nidus
 
 A self-hosted CalDAV, CardDAV, and WebDAV server written in Go, backed by a
-filesystem store. HTTP Basic Auth (bcrypt) with per-user isolated collections.
+filesystem store, with calendar/address book sharing grants tracked in a
+small SQLite database. HTTP Basic Auth (bcrypt) with per-user isolated
+collections.
 
 ## Build, test, lint
 
@@ -14,7 +16,9 @@ make tidy            # go mod tidy
 go test ./internal/store/ -run TestStoreRoundTrip -v   # single test
 ```
 
-There is currently only one test file: `internal/store/store_test.go`.
+Test files: `internal/store/store_test.go`, `internal/webdav/handler_test.go`,
+`internal/db/shares_test.go`, `internal/caldav/backend_test.go`,
+`internal/carddav/backend_test.go`.
 
 ## Architecture
 
@@ -76,6 +80,25 @@ There is currently only one test file: `internal/store/store_test.go`.
   (`QueryCalendarObjects`) currently list all objects and filter in-memory
   via `caldav.Filter` — fine for small collections, not optimized for
   scale.
+  **Sharing**: both backends take an `*db.DB` (may be `nil` to disable
+  sharing). A calendar/address book shared with a user is exposed under
+  the synthetic local name `<owner>~<name>` (see `sharedNameSep`,
+  `sharedCalendarName`/`sharedBookName`) in that user's own home-set —
+  `resolveCalendar`/`resolveBook` split the local name back into
+  owner+real name and check the grant's permission (`db.PermRead`/
+  `db.PermWrite`) via `dbase.CalendarShareFor`/`AddressBookShareFor`
+  before allowing reads (any share) or writes (write share only). The
+  shared data is never copied — it's read/written directly under the
+  owner's own `store.Store` namespace, just addressed via the synthetic
+  name from the grantee's requests.
+- `internal/db` — a small `database/sql` wrapper around
+  `modernc.org/sqlite` (pure Go, no CGO) at `<data_dir>/nidus.db`. Only
+  one open connection is used (`SetMaxOpenConns(1)`) since SQLite allows a
+  single writer; this is intentionally simple and not meant to scale to
+  heavy concurrent write load — fine for sharing grants (and future user
+  management), not a general-purpose data store (that's what
+  `internal/store` is for). Schema lives in `migrate()`; there's no
+  migration framework, just idempotent `CREATE TABLE IF NOT EXISTS`.
 - `internal/webdav` — plain-file WebDAV via `golang.org/x/net/webdav`,
   mounted at the single fixed URL `/files/` for all users (no username in
   the path either). `NewHandler` caches one `*xwebdav.Handler` per