User Story: Allow PersonPicker consumers to filter search results with a callback

## Story
As an app developer using `PersonPicker`, I want to provide a custom filter callback for search results, so that I can exclude people that are not valid for my workflow before the user selects them.

## Context
Consumers of `PersonPicker` can already configure built-in picker behavior, but some applications need domain-specific filtering that cannot be expressed with the current coarse options alone. A common example is limiting the result set to certain `accountType` values, but the same need can apply to other business rules.

Without a custom filter hook, each consumer must either accept irrelevant search results in the UI or re-implement filtering behavior outside the component, which creates inconsistent UX and duplicated logic.

## Functional Requirements
- `PersonPicker` exposes an optional callback prop that receives each candidate search result and returns whether it should be shown to the end user.
- The callback is applied before search results are rendered in the picker result list.
- The callback supports filtering scenarios such as allowing only specific `accountType` values.
- When no callback is provided, `PersonPicker` keeps its current behavior.
- Filtered-out results cannot be selected through the normal picker interaction.
- The component documentation includes at least one example showing how a consumer can filter by `accountType`.

## Acceptance Criteria
- [ ] **Given** a `PersonPicker` without a custom filter callback, **When** a user searches for people, **Then** the component behaves the same as today.
- [ ] **Given** a `PersonPicker` with a custom filter callback that allows only selected account types, **When** the search API returns mixed account types, **Then** only the allowed results are shown in the result list.
- [ ] **Given** a `PersonPicker` with a custom filter callback, **When** a result does not satisfy the callback, **Then** that result is not selectable from the picker UI.
- [ ] **Given** the new filter callback prop is available, **When** a consumer reads the component docs or story examples, **Then** they can find a clear example of filtering search results by `accountType`.

## Notes
- Target repository: `equinor/fusion-react-components`
- Component scope: `PersonPicker` (single-person picker); implementation should evaluate whether the same API should also be exposed on `PeoplePicker`, but that is not required for this story unless the component architecture makes parity necessary.
- Suggested prop shape for discussion: `filterResult?: (person) => boolean` or equivalent naming that matches existing component conventions.
- Non-goal: changing the People API query contract. This story is about client-side filtering of returned search candidates.
- Suggested implementation discussion: align callback naming and argument type with the existing public person model exposed by the component package.

## Metadata
- Issue type: User Story
- Duplicate check: No open or closed duplicates found from focused searches for `PersonPicker filter`, `accountType picker filter`, and `peoplepicker filter callback` in `equinor/fusion-react-components`.