BasicInterceptor treats 403 on /rest/dev-status as invalid credentials, cascading to block all subsequent API requests

## Describe the bug
When a Jira Cloud user lacks the "View Development Tools" project permission, the extension's dev-status fetch returns a 403 Forbidden. The HTTP interceptor (BasicInterceptor) incorrectly treats this permission error as an authentication failure, setting a session-wide _invalidCredentials flag that blocks every subsequent API request until the session is restarted.

## To Reproduce
1. Authenticate against a Jira Cloud site using an unscoped API Token.
2. Ensure the authenticated account does not have the "View Development Tools" project permission.
3. Open any Jira issue in the extension's issue panel.
4. Observe the VS Code Output panel (Atlassian extension channel) and note the credential error alert.

## Expected behavior
The 403 from /rest/dev-status/1.0/issue/detail is caught, logged as a permissions error, and the extension falls back to local data for the development info panel. All other API calls (JQL queries, issue updates, avatars) continue to work normally.

## Relevant log output from the extension Output channel
> Could not fetch Jira development info, falling back to local data AxiosError: Request failed with status code 403
> Failed to execute default JQL query for site Error: Credentials are invalid. Please update your credentials.
> Error fetching image: [https://**TEXT_REDACTED**.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/**NUMBER_REDACTED**?size=medium] Error: Credentials are invalid. Please update your credentials.
> Error updating issue Error: Site previously failed authentication

## Environment and Version:
- Atlassian Plugin Version: 4.0.31
- Visual Studio Code Version: 1.126.0
- OS: Windows 11

## Additional context
The root cause appears to be in BasicInterceptor._errorInterceptor, which fires on any 401 or 403 response and unconditionally invalidates credentials for the entire session:

```401 !== response?.status && 403 !== response?.status || (
this._invalidCredentials = true,
this.authStore.handleApiUnauthorized(this.site)
)
```

A 403 from a permission-gated endpoint is not an authentication failure — the token is valid, the user simply lacks a specific Jira project permission. The dev-info fetch is wrapped in a try/catch that would otherwise handle this gracefully, but the Axios interceptor sets the flag before the catch block runs.

## Suggested fix:
Limit credential invalidation to 401 responses. 403 responses should be surfaced as permission errors for that specific request, not treated as session-wide credential failures.

Start with BasicInterceptor._errorInterceptor and trace the /rest/dev-status/1.0/issue/detail request through the development-info fetch. Verify that a 403 is handled as a permission error, local development data remains available, and later JQL, avatar, and issue-update requests continue to work without restarting the session.

Written by the indexing model from the issue text.