Add required flag to DIVE_PARAM

[mattdawkins]

Summary

Pipelines can now mark a `DIVE_PARAM` as required so the user can't run the pipeline until they supply a value, and `config ` lines (kwiver globals) can be DIVE_PARAM targets — same syntax, parser-side recognition only.

Spec

```
:my:key = 0.5 # DIVE_PARAM ["My label", float, required]

config global:fps = 5 # DIVE_PARAM ["FPS", int, required]
```

`required` is a flag keyword in the DIVE_PARAM comma list — stripped from `type_props`, sets `required: true` on the param.

Coverage

• Top-level assignments (`:key = value`) — keyed under `process:block...:key` from surrounding `process` / `block` context.
• Nested `block` declarations — context stack pushes/pops per `block` / `endblock`, so e.g. `process tracker → block matcher → block weights → :iou` keys as `tracker:matcher:weights:iou`.
• `config absolute:key = ` — absolute kwiver key, no process/block prefix applied. Used for globals referenced from multiple sites.

Changes

• `apispec.ts` / `server/dive_utils/types.py`: `required?: boolean` on `DiveParam`.
• `pipeline_discovery.py` (server) + `platform/desktop/backend/native/common.ts` (desktop): recognise the `required` keyword in the type-props list, plus `config = ` lines as DIVE_PARAM targets.
• `PipelineParamsDialog`: red `*` on the label, vuetify rule on the input that blocks the Run button when empty.

[Louis-Pagnier-KW]

Hi,
Thanks for this nice addition!
I am questioning myself if it could be better to change the param behavior to be keyword instead of positional.

For example to pass from:
# DIVE_PARAM["Max points", range_int, 0, 100, 5]
to
# DIVE_PARAM["Max points", range_int]{min=0, max=100, step=5}

And we would be able to combine it with the required argument:
# DIVE_PARAM["Max points", range_int]{min=0, max=100, step=5, required=true}

It is a bit more verbose, but I think it could be more scalable, add avoid problems if later we have a string parameter for a type.
The main advantage would also be that we will not have to add the required field to types, but directly use the generic params dict.

What do you think of this?

[Louis-Pagnier-KW]

I think we can integrate the rule directly in the rules dict to have it consistent.

Suggested change

	}
	const rules: Record<string, ValidationRule> = {
	integer: (value: string | number) => Number.isInteger(Number(value)) || 'Please enter a whole number',
	positive: (value: string | number) => Number(value) >= 0 || 'Please enter a number ≥ 0',
	strictlyPositive: (value: string | number) => Number(value) > 0 || 'Please enter a number > 0',
	required: (value: string | number) => (value !== undefined && value !== null && value !== '') || 'This field cannot be empty',
	};
	function getRules(type: PipelineParamType, required = false): ValidationRule[] {
	const res: ValidationRule[] = [];
	if (required) {
	res.push(rules.required);
	}
	if (type.includes('int')) {
	res.push(rules.integer);
	}

[Louis-Pagnier-KW]

Otherwise looks good to me