Add WireMock best practices

[jabrena]

User story

As a maintainer or contributor using this repository's agent skills,
I want a dedicated cross-cutting technology skill and system prompt for WireMock (702-technologies-wiremock),
So that agents have a single, framework-agnostic entry point for HTTP stubbing and contract-testing best practices without having to load Spring Boot, Quarkus, or Micronaut testing skills first.

Context

• The 700–799 band is reserved for technologies not tied to one Java HTTP stack (AGENTS.md — Skill and system-prompt numbering).
• 701 is OpenAPI 3.x (701-technologies-openapi). 702 should be WireMock as a shared testing/stubbing technology, analogous to how 701 isolates contract guidance from framework REST skills.
• Framework-specific integration-test skills (132, 322, 422, 522) may reference WireMock in context; 702 documents portable WireMock practices (isolation, mappings, lifecycle, verification, common pitfalls) and defers framework bootstrapping and extension-specific setup to those skills.

Acceptance criteria

1. Given the repository follows the skills-generator layout, when 702-technologies-wiremock is implemented, then it includes PML XML sources: system-prompts/702-technologies-wiremock.xml and skills/702-skill.xml (or equivalent naming consistent with 701) with skill id 702-technologies-wiremock.

2. Given skill-inventory.json and system-prompt-inventory.json, when the change is complete, then skill id 702 is registered in both inventories.

3. Given a developer runs ./mvnw clean verify -pl skills-generator and installs the generator, when skills are regenerated, then the generated skills/ output includes the new WireMock technology skill with triggers and scope that emphasize framework-agnostic stubbing and testing guidance.

4. Given the project validation pipeline, when contributors run ./mvnw clean verify -pl skills-generator and npx skill-check skills as applicable, then checks pass for the new artifacts.

5. Given an OpenSpec-driven workflow for complex additions, when this work is planned or reviewed, then an OpenSpec change (proposal/spec/tasks) for 702 may mirror the structure used for 701-technologies-openapi (optional but recommended for alignment).

Out of scope (explicit)

• Replacing or duplicating full framework integration-test skills; those remain the home for @SpringBootTest / @QuarkusTest / @MicronautTest + Testcontainers wiring.
• Vendor-specific or version-pinning documentation unless needed for stable, copy-paste-safe examples.

Related numbering

Id	Artifact
701	701-technologies-openapi
702	702-technologies-wiremock (this issue)

[jabrena]

#636