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

[mattdawkins]

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?

Probably a good idea if we plan on adding a lot more parameters, though my text editor is starting to get sad because the max line ending on these pipes and that would further extend it. I'm kind of hoping we can partially do away with this system at some point because of that (e.g. taking the kwiver type definitions and adding max ranges and things to those macros so they don't need to be re specified). So I'm fine if it goes in as it is now because I want to refactor this eventually anyway.

Another thing I wouldn't mind doing is just adding a quick comment up here next to the parameters like # DP1, #DP2 for short, then define the actual parameters for DIVE elsewhere in the file, like references in a latex paper

[BryonLewis]

Going to merge for proper testing of the pipeline params withe newer sealion metadata pipelines