fix(core): classify EACCES as permission_denied, not auth_failed

[shuvamk]

Problem

MESSAGE_PATTERNS in packages/core/src/connectivity.ts is documented as "Ordered most-specific → least", but the auth rule carries a bare permission denied token and sits first:

[/… |permission denied|publickey|authentication failed|…/i, "auth_failed"],
…
[/eacces|…|access denied|forbidden|read-only|not writable/i, "permission_denied"],

Node spells a filesystem permission error as EACCES: permission denied, <syscall> '<path>' — which contains permission denied, so it matches the auth rule first.

Consequences:

1. Every EACCES is classified auth_failed.
2. The eacces alternative in the permission_denied rule is unreachable for real Node fs errors.
3. permission_denied — documented as "authed, but not allowed to do the thing (e.g. write path)" — never fires for the exact case its comment names.

Executed on main:

EACCES: permission denied, open '/backups/openship/db.sql'  -> auth_failed        ✗
EACCES: permission denied, mkdir '/mnt/backup/nightly'      -> auth_failed        ✗
EROFS: read-only file system, open '/srv/backups/x'         -> permission_denied  ✓
Error: access denied writing to /srv/backups                -> permission_denied  ✓

So two ways of saying the same thing already disagree today.

Impact

ConnectivityCode exists so "UIs can map copy once", per the type's own comment — the code drives what the operator is told. An operator whose backup destination directory isn't writable gets "credentials rejected" and goes off rotating SSH keys or re-entering a password, when the actual fix is chown/chmod on the destination path.

Fix

Match the errno tokens ahead of the auth rule:

[/eacces|erofs/i, "permission_denied"],

EACCES / EROFS never appear in SSH's Permission denied (publickey) or Permission denied, please try again, so the errno rule can't swallow genuine auth failures. The auth rule keeps its permission denied token for those.

Tests

Two cases added to the existing packages/core/test/connectivity.test.ts (@repo/core 101 → 103):

• permission_denied for EACCES (open + mkdir) and EROFS
• auth_failed still for Permission denied (publickey) and Permission denied, please try again — pinning the boundary so the new rule can't widen later

Verified against the unfixed source: the filesystem case fails, the SSH guard passes either way. All pre-existing expectations in that file are untouched.

Full suite: bun run test → 5/5 turbo tasks successful (api 714, adapters 240, core 103, db 25, dashboard 17).