Avoid panic when a registered named block omits its label

## Summary

`NewBaseBlock` assumes every non-nil `HclBlock` has at least two labels and reads `hb.Labels[1]` unconditionally. A syntactically valid but malformed named block can therefore crash the process during `InitConfig` instead of producing a diagnostic.

Observed on `main` at commit `1d1c394b55ea36a8dc98495850430e4da643b1eb`.

## Reproduction

Register a root block whose implementation uses the normal empty subtype and a two-segment address, then parse and initialize this HCL:

```hcl
module {
source = "./child"
}
```

`readRawHclSyntaxBlock` prepends the synthetic empty subtype label, leaving `Labels == []string{""}`. `wrapBlock` constructs the registered block, and `NewBaseBlock` evaluates `hb.Labels[1]`.

## Actual behavior

The process panics with an index-out-of-range error from `NewBaseBlock`:

https://github.com/Azure/golden/blob/1d1c394b55ea36a8dc98495850430e4da643b1eb/base_block.go#L25-L29

## Expected behavior

Invalid label cardinality should return an HCL diagnostic or ordinary error with the block source range. Configuration input should not be able to panic the host process.

## Suggested direction

Validate the registered block's required label count before constructing `BaseBlock`, or make `NewBaseBlock` bounds-safe and report label-schema errors at the wrapping boundary. A regression test should cover missing and extra labels for registered named blocks.

Start with base_block.go at NewBaseBlock, then trace readRawHclSyntaxBlock and wrapBlock through InitConfig to understand where labels are normalized and validated. Add coverage for missing and extra labels on registered named blocks, and run the relevant Go test suite to verify invalid input returns a diagnostic or error with its source range instead of panicking.

Written by the indexing model from the issue text.