Normalize TypeSpec path inputs ending in tspconfig.yaml for release plan updates

[Copilot]

azsdk_update_release_plan and related TypeSpec path handling assumed a project-directory input and could mis-handle paths that already included tspconfig.yaml (e.g., appending it again). This change normalizes both relative and absolute .../tspconfig.yaml inputs to the project root before validation/parsing/path extraction.

• Path normalization in TypeSpec model parsing

  • Updated TypeSpecProject path handling to canonicalize inputs:
    • specification/.../service/tspconfig.yaml → specification/.../service
    • /abs/.../service/tspconfig.yaml → /abs/.../service
  • Applied consistently in:
    • IsValidTypeSpecProjectPath
    • ParseTypeSpecConfig

• Helper-level sanitization for release-plan flows

  • Updated TypeSpecHelper to treat tspconfig.yaml inputs as project-root paths in:
    • ParseTypeSpecProjectAsync
    • GetTypeSpecProjectRelativePath
  • Relative path extraction now returns the project path (not the config file path), preserving expected specification/... behavior.

• Focused test coverage

  • Added tests to verify:
    • validation succeeds for both relative and absolute .../tspconfig.yaml inputs
    • relative-path extraction strips tspconfig.yaml
    • UpdateReleasePlan succeeds with both relative and absolute .../tspconfig.yaml inputs

var relativeConfigPath = "specification/containerservice/.../fleet/tspconfig.yaml";
var absoluteConfigPath = Path.GetFullPath(relativeConfigPath);

// Both are normalized to project root before validation/parsing/path extraction.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.