[TASK] Enforce filterRules restrictions on Workspace create and update

### Certification

- [x] I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

### Description

🛑 **Depends on:** #846 (rule evaluation engine must be implemented)

When a user creates or updates a Workspace, the backend must validate that the selected `imageConfig`
and `podConfig` options are not restricted by filterRules. If a selected option would have
`restrictions.deny: true` given the workspace's namespace context, the backend must reject the
request with an appropriate error message.

This is the server-side enforcement layer — even if the frontend correctly hides or disables
restricted options, the backend must independently validate to prevent direct API misuse.

#### Goals
- On Workspace create: evaluate filterRules for the selected imageConfig and podConfig using the
workspace's target namespace context
- On Workspace update: evaluate filterRules if imageConfig or podConfig is being changed
- Return HTTP 403 or 422 with the `denyMessage.text` from the matched rule
- Unit tests

#### Implementation

1. In the Workspace create/update handler, after validating the request body:
a. Look up the WorkspaceKind
b. Evaluate IMAGE_CONFIG-scoped filterRules for the selected imageConfig
c. Evaluate POD_CONFIG-scoped filterRules for the selected podConfig
d. If either has `api.deny: true` → reject with the rule's `denyMessage.text`
2. Reuse the evaluation engine from #846

### Acceptance Criteria

- [ ] Workspace create is rejected when selected imageConfig has `restrictions.deny: true`
- [ ] Workspace create is rejected when selected podConfig has `restrictions.deny: true`
- [ ] Workspace update is rejected when changing to a restricted imageConfig or podConfig
- [ ] Error response includes the `denyMessage.text` from the matched filterRule
- [ ] Workspace create/update succeeds when no rules restrict the selected options
- [ ] Unit tests cover deny enforcement for both create and update paths