fix: discover workspaces in pnpm and yarn monorepos (EGB-1232)

Workspace patterns came from package.json's `workspaces` key only, at both
call sites. pnpm declares them in pnpm-workspace.yaml instead, so no pnpm
monorepo ever resolved a workspace: `push -w` refused outright, and plain
`push` failed silently — _maybe_workspace_env_files returned 0 the moment
the key was absent, leaving the auto-discovery that covers push's root-only
scan inert and printing "Nothing new to add", indistinguishable from a repo
with genuinely nothing new. That silence cost two sessions on the same repo.

Both call sites now resolve through one shared source, _workspace_patterns:
package.json when it declares any, else pnpm-workspace.yaml's `packages:`
block. The YAML read is deliberately not a parser — block sequence only,
stopping at the next top-level key so pnpm 10's onlyBuiltDependencies:/
catalog: cannot leak in as globs, with quote/comment handling and a symlink
refusal.

Also fixes yarn's object form. `.workspaces // .workspaces.packages | .[]`
short-circuits on the truthy object, iterating its values and yielding the
pattern array as one token; only npm's array form ever worked. Note the
obvious reorder is NOT the fix — `.workspaces.packages` errors on an array —
so the filter is type-aware.

Patterns are validated before reaching the unquoted glob expansion (no
absolute paths, `..`, metacharacters, or whitespace; pnpm `!` negations
skipped), matching the .secrets-store/.secrets-files posture. jq is now
required only when package.json is the source. A monorepo-shaped root that
resolves nothing warns and points at `secrets add` instead of returning in
silence, and `-w`'s error names pnpm-workspace.yaml when that is the file
present.

Scope note: the workspace re-scan still runs only for projects that already
have a .secrets.json — push's root-scan-only first push is by design
(EGB-677 E13), and this bug is the fallback covering it never engaging.

test/workspaces.bats: 18 new tests. Full suite 371/371 green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BrUoYuUMoTj91rzV4vxGPB

README.md

@@ -425,10 +425,10 @@ git commit -am "switch to personal secrets"
 
 ### Monorepo support
 
-For projects with multiple packages (monorepos using `package.json` workspaces), add the `-w` flag to operate on all workspaces at once:
+For projects with multiple packages, add the `-w` flag to operate on all workspaces at once:
 
 ```bash
-cd ~/myapp                  # has package.json with "workspaces": ["apps/*", "packages/*"]
+cd ~/myapp                  # npm/yarn workspaces, or a pnpm-workspace.yaml
 secrets push -w             # encrypts secrets from root + each workspace
 secrets pull -w             # decrypts into root + each workspace directory
 secrets clear -w            # clears secrets from root + each workspace
@@ -445,7 +445,22 @@ Inside `~/.secrets/`, workspace secrets are organized by path:
     apps/api/.env.age               # api workspace
 ```
 
-Requires `jq` (`brew install jq`).
+**Where workspaces are declared.** All three package managers are supported:
+
+| Manager | Declaration |
+|---|---|
+| npm | `package.json` → `"workspaces": ["apps/*"]` |
+| yarn | `package.json` → `"workspaces": {"packages": ["apps/*"]}` |
+| pnpm | `pnpm-workspace.yaml` → `packages:` block |
+
+`package.json` wins when it declares any workspaces; `pnpm-workspace.yaml` is
+the fallback. Reading `package.json` requires `jq` (`brew install jq`); a
+pnpm-only repo needs no jq for workspace discovery.
+
+If a root *looks* like a monorepo (a `pnpm-workspace.yaml` or a `packages/`
+directory) but no workspace packages can be read from it, `secrets push` says
+so on stderr rather than silently discovering nothing — that silence
+previously made a pnpm repo indistinguishable from one with nothing to sync.
 
 ### External files (Gradle properties)