feat: parse and expose OpenAPI operation tags

[MaxMichel2]

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 feat: NetworkMock listing, filtering, and sorting improvements #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).