[BUG]

## Describe the bug

`linkedin-create-image-post-user` fails with an HTTP 403 during the `initializeUpload` step when the connected LinkedIn account does not have the `openid` scope.

The action builds the upload owner URN using `this.linkedin.$auth.oauth_uid`, but this value is empty when `openid` is not granted. As a result, the request sends:

```js
owner: "urn:li:person:"
```

and LinkedIn rejects the upload initialization request with a 403.

The equivalent action `linkedin-create-text-post-user` works correctly because it resolves the member ID through `getCurrentMemberProfile()` (`/me`) instead of relying on `oauth_uid`.

---

## To Reproduce

1. Connect a LinkedIn account through the managed LinkedIn app.
2. Ensure the account has posting scopes such as:

* `w_member_social`
* `r_basicprofile`
* other social/organization scopes
3. Ensure the connection does **not** include the `openid` scope.
4. Run **Create a Simple Post (User)**.

* Result: succeeds.
5. Run **Create Image Post (User)** using any valid image URL or file.

* Result: fails with HTTP 403 during `initializeUpload`.

Error returned by LinkedIn:

```json
{
"message": "",
"status": 403
}
```

Response headers include:

```text
x-linkedin-error-response: true
```

---

## Expected behavior

`linkedin-create-image-post-user` should resolve the member ID in the same way as `linkedin-create-text-post-user` and successfully create image posts for accounts that have `w_member_social`, regardless of whether the `openid` scope is granted.

The owner should be resolved from:

```js
const { id } = await this.linkedin.getCurrentMemberProfile();
```

instead of:

```js
this.linkedin.$auth.oauth_uid
```

---

## Screenshots

Not applicable.

---

## Additional context

Relevant findings:

* `GET /v2/userinfo` returns **403** because the connection does not have the `openid` scope.
* `GET /v2/me` returns **200** and provides the member ID.
* Text posts created through `linkedin-create-text-post-user` succeed with the same account and scopes.
* Image upload itself works when a valid owner URN is provided.
* The issue appears isolated to how the owner URN is generated during `initializeUpload`.

Environment:

* Pipedream Connect (managed auth)
* Production environment
* Authorized scopes include:

* `r_basicprofile`
* `w_member_social`
* `w_member_social_feed`
* `w_organization_social`
* `w_organization_social_feed`
* additional organization/ads scopes
* No `openid` scope granted.