feat: parse and expose OpenAPI operation tags

Read OpenApiDocument.kt, OpenApiParser.kt, MockConfiguration.kt, and NetworkMockEndpointScreen.kt to trace parsing, the public Operation model, and existing grouping UI. Inspect MockConfigRepositoryTest.kt and sample specs for fixture patterns, then resolve the FilterChip versus sticky-header choice with maintainers before implementation. Done means tags are parsed, exposed, represented in a fixture and tests, documented, reflected in the API dump, and supported by the chosen UI.

Summary

Follow-up from #114. That issue's design deliberately deferred OpenAPI tags support: no spec in this repo (sample or test fixture) currently declares tags, so parsing and surfacing them would be speculative work with no real usage to validate against — parser change, public API change to Operation, sample-spec edits, doc updates, and new tests, all for a field nobody currently emits.

OpenApiDocument.kt's file KDoc already documents this as a deliberate, currently-unparsed field: "Only fields consumed by OpenApiParser are modeled. Everything else in a real spec (deprecated, tags, security, request bodies, schemas, …) is silently ignored via lenient/non-strict decoding."

Scope, when picked up

• Add tags: List<String> = emptyList() to the internal OperationObject (devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/openapi/OpenApiDocument.kt) and thread it into the public Operation model (MockConfiguration.kt) via OpenApiParser.kt.
• This is a public API change to Operation — requires :devview-networkmock-core:apiDump and doc updates (docs/modules/networkmock-core.md, module CLAUDE.md).
• UI: either a third FilterChip row (mutually exclusive with "no groups" for untagged specs — same hidden-when-empty pattern as the version and method rows added in #114), or sticky-header grouping in the operation list (precedent: NetworkMockEndpointScreen.kt's existing stickyHeader grouping by status-code family).
• Needs at least one test fixture spec with tags declared — none currently exist in MockConfigRepositoryTest.kt's inline JSON, the sample app's specs, or anywhere else in the repo.

Open question

Chip row vs. sticky-header grouping — resolve at design time before implementing, not here (same as #114's original open-questions approach).