Issue for this PR

Fixes the permission-denied server errors in #50951.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Focuses only on reporting permission errors during Location boot. Builds on #52649 and #52668, which already classify filesystem permission failures and return 404 for missing Location folders.

• Keeps FileSystem.DirectoryAccessDeniedError typed through Instance.layer instead of turning it into a defect and returning 500.
• Classifies permission defects from earlier boot steps, such as config discovery, when the denied path is the Location directory or one of its parents. Handles EACCES and macOS privacy denials reported as EPERM; unrelated failures remain defects.
• Returns LocationPermissionDeniedError (403) through the existing Location error mappings, with the corresponding Protocol and generated client declarations.

No new filesystem checks are added. location.get, filesystem boot canonicalization, and the Workerd filesystem replacement match v2. Cached Locations are not rechecked when their folders become inaccessible after boot. Missing-folder behavior and desktop UI are unchanged.

How did you verify your code works?

• bun run check from the repository root.
• 65 focused tests passed across server fetch, Workerd, Location filesystem, Location layer, and session movement suites.
• Permission coverage in packages/server/test/fetch.test.ts verifies that a denied parent folder returns 403 for model and Location requests, recovers after access is restored, and does not recheck cached access after permissions are revoked again.
• Existing missing-folder 404 and recovery coverage still passes.
• Regenerated the client with bun run generate.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR