Drop the scope segment from the API key create path

[vrv-panw]

POST /api-keys/{type}/{sub-type} took the scope as a path segment, with type an enum of organisation | workspace — so every workspace-scoped call rendered as /api-keys/workspace/user. The scope comes from the calling token, which is the same reasoning behind dropping organisation_id as a parameter, so the segment restated what the request already carries, in a public URL.

The path is now POST /api-keys/{sub-type}; sub-type is unchanged (user | service).

Docs URL moves — /aigw/api-reference/api-keys/post-api-keys-by-type-by-sub-type → /aigw/api-reference/api-keys/post-api-keys-by-sub-type. Recorded in _project/hrefs.yaml; a redirect on the docs site may be wanted.

Left alone deliberately: the workspace_id query parameter on GET /api-keys. It is not a path segment, so it is a separate question.

Touched files beyond the spec are the decision files and generated artifacts — _project/hrefs.yaml, _project/planes.yaml, overlays/docs-prose.yaml, plus docs-navigation.json and build-report.txt from scripts/build.py. scripts/check.py passes.

🤖 Generated with Claude Code

[github-actions]

⚠️ 1 breaking change(s) in openapi.yaml

1 changes: 1 error, 0 warning, 0 info
error	[api-path-removed-without-deprecation] at /tmp/base.yaml
	in API POST /api-keys/{type}/{sub-type}
		api path removed without deprecation

This does not block the merge. A breaking change is sometimes the
correct change. It does mean any KB claim describing these
operations should be reviewed, and the spec.changed webhook will
carry the grading to the KB on merge.