Potential regression with extender cross-LPAR copy

[traeok]

Describe the bug

There seems to be a regression with cross-LPAR copy for extender profiles causing an error to appear when the extender hasn't implemented that API.

To Reproduce

while testing this and doing a copy/paste of a single file I was prompted for member name, then it recognized that it already existed and asked if I would like to overwrite existing which I clicked yes but got a 404 returned Rest API failure with HTTP(S) status 404 This is same LPAR but different profiles, and it previously worked when tested initial introduction of feature

The test steps above should be a copy/paste where there is no overwrite or prompt to replace. This sounds like a valid issue but not sure that my changes have introduced this as I haven't made any changes to Zowe Explorer. I can test again w/ the CLI to see if I can reproduce it there (as I've only made a code change to the SDKs), if I can't I think we should address it separately.

In addition, the error you're seeing is from a change made in ZE from 9 months ago, introduced in #3387:

zowe-explorer-vscode/packages/zowe-explorer/src/trees/dataset/DatasetActions.ts

Lines 1935 to 1945 in 170dc9c

	if (node.getProfile().name === clipboardContent[0].profileName) {
	await ZoweExplorerApiRegister.getMvsApi(node.getProfile()).copyDataSetMember(
	{ dsn: content.dataSetName, member: content.memberName },
	{ dsn: node.getLabel().toString(), member: memberName },
	{ replace: replace == "replace" ? true : false }
	);
	} else {
	if (mvsApi?.copyDataSetCrossLpar == null) {
	await Gui.errorMessage(vscode.l10n.t("Copying data sets cross lpars is not yet supported for this profile."));
	return;
	}

Originally posted by @traeok in #3896 (comment)

[github-actions]

Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[JillieBeanSim]

after investigation, the extender did not have new API but did work prior to this change so this could be considered a breaking change. The extender will adopt the new API sometime in the future but we may still need to find a way to handle this without breaking extenders as I am unaware of how many may have previously worked and now doesn't