Initializing Shader Matrix Parameter Relative To World Writes Random Values to .oso

This isn't a big issue - it should perhaps just be illegal to do, but currently oslc accepts it, and produces a randomly varying .oso, which isn't good.

If I write a shader like this:
```
shader UninitializedMatrix
(
matrix projectionOrigin = matrix( "world", 1 ),
)
{
printf( "%f\n", projectionOrigin );
}
```

and then repeatedly run:
```oslc UninitializedMatrix.osl && testshade UninitializedMatrix```

I get varying results such as:

```0.000000 1.000000 0.000000 0.000000 -0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000```

```0.000000 1.000000 0.000000 0.000000 8667008283398819024714655604160856064.000000 0.000000 0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000```

```0.000000 1.000000 0.000000 0.000000 2573104625500368666624.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1913952141312.000000 0.000000 0.000000 0.000000 160447971328.000000 0.000000```

Worst case, I had a situation where the parameter would always be connected to something, so I hadn't noticed that the initializer wasn't working, until one compile hit some particularly bad luck and wrote a nan into the .oso, which caused the .oso to fail to parse.

Not a problem for me now that I'm aware, but perhaps to make it more obvious to others this should be an error, or should receive an identity matrix even though the actual world matrix isn't know yet during compile?

I'm testing in 1.7.2 on Linux, in case this behaviour has changed recently.

Reproduce the issue with the provided UninitializedMatrix shader by running oslc followed by testshade repeatedly and compare the printed matrix values. Trace how oslc handles the world-relative matrix initializer, then determine the intended behavior—rejecting it or using an identity matrix—and add coverage for deterministic output or a diagnostic.

Written by the indexing model from the issue text.