Plan migration to @equinor/fusion-services and deprecate module-services

## Objective

Plan and execute the migration of service APIs from
`@equinor/fusion-framework-module-services` to the function-based,
service-subpath architecture in `@equinor/fusion-services`, then deprecate the
legacy module package when consumers have a supported migration path.

## Context

`@equinor/fusion-services` introduces independently importable service APIs such
as:

```ts
import { getRole } from '@equinor/fusion-services/roles';
```

This avoids the monolithic client/provider graph in
`@equinor/fusion-framework-module-services`, improves endpoint-level tree
shaking, and couples endpoint argument and response types to the selected API
version.

Maintaining both packages as independent implementations is not a sustainable
end state. It would duplicate endpoint ownership and documentation, allow
runtime schemas and service contracts to drift, leave consumers uncertain about
the preferred API, and retain unnecessary coupling between service access and
the Fusion Framework module lifecycle. A staged migration followed by
deprecation provides one canonical implementation while preserving a safe
transition for existing consumers.

The Roles V2 implementation establishes the initial package architecture:

- named endpoint functions under service-specific package subpaths
- version-discriminated request and response types
- version-scoped Zod schemas as the runtime and type source of truth
- versioned, exported OpenAPI snapshots
- remote OpenAPI drift detection

## Scope

### In scope

- [ ] Inventory every service and public API currently exposed by
`@equinor/fusion-framework-module-services`.
- [ ] Identify active consumers and migration risks for app state, bookmarks,
context, notification, people, and any remaining service clients.
- [ ] Define the target `@equinor/fusion-services/` API for each
service.
- [ ] Define how authentication, service discovery, promise APIs, observable
APIs, runtime validation, and API versioning work without the module
provider abstraction.
- [ ] Migrate service implementations without maintaining two independent
endpoint/schema implementations.
- [ ] Publish migration documentation with before-and-after examples.
- [ ] Define the deprecation release for
`@equinor/fusion-framework-module-services`, including TSDoc, README,
package metadata, and release notes.
- [ ] Define a supported deprecation period and criteria for eventual removal.
- [ ] Measure representative consumer bundles before and after migration.

### Out of scope

- Immediate removal of `@equinor/fusion-framework-module-services`.
- Breaking existing consumers before equivalent APIs and migration guidance are
available.
- Moving unrelated framework modules into `@equinor/fusion-services`.

## Planning output

- Ordered migration plan by service.
- Compatibility and deprecation policy.
- Consumer inventory and migration owners.
- Package and API-versioning strategy.
- Validation and bundle-size acceptance criteria.
- Release milestones for introduction, deprecation, and eventual removal.

## Risks and decisions to resolve

- Determine whether legacy APIs should temporarily delegate to
`@equinor/fusion-services` or remain unchanged until deprecation.
- Avoid retaining framework module dependencies in the new transport-neutral
package unless they are explicitly part of its contract.
- Ensure service-specific imports remain mandatory; do not introduce a
monolithic `@equinor/fusion-services` root namespace.
- Keep versioned OpenAPI snapshots and runtime schemas synchronized with remote
service contracts.
- Establish how long observable APIs must remain supported during migration.

## Done when

- [ ] Every legacy service has a documented target and migration order.
- [ ] Dependencies, owners, risks, and release milestones are documented.
- [ ] Deprecation criteria and consumer communication are approved.
- [ ] Follow-up implementation issues are created and ordered.
- [ ] The plan has been reviewed by framework maintainers and representative
consumers.

## Notes

The Roles V2 package work should be used as the reference implementation for
tree shaking, API-version discrimination, schema inference, OpenAPI snapshots,
and drift detection.