[Enh]: Complete our OpenAPI implementation

### What

Improve DAB’s OpenAPI generation. Enhance with OpenAPI 3.1.

### Enhancements

#### 1. Per role OpenAPI generation

The OpenAPI document must reflect the permissions and visibility for each role.

* `https://localhost:8080/openapi` → current role by context
* `https://localhost:8080/openapi/anonymous` → anonymous role
* `https://localhost:8080/openapi/authenticated` → authenticated role
* `https://localhost:8080/openapi/{custom-role}` → specific custom role

Each variant filters entities, fields, and methods according to that role’s access.

#### 2. Multi data source awareness

Each operation must indicate which configured data source it targets.

```json
"paths": {
"/api/Author": {
"get": {
"summary": "Get all authors",
"x-data-source": "sql1", // from data-source.name
"responses": { }
}
}
}
```

`x-data-source` maps directly to the `data-source.name` defined in configuration.

#### 3. Include and exclude field support

When entity configuration includes `include` or `exclude`, only permitted properties appear in the OpenAPI schema.

```json
"components": {
"schemas": {
"Author": {
"type": "object",
"properties": {
"id": { "type": "integer" },
"name": { "type": "string" } // for example
}
}
}
}
```

#### 4. Request body strict mode

When `request-body-strict` is enabled, the request and response payloads share the same schema.
Keys are optional in update operations but otherwise identical.

#### 5. Permissions driven REST methods

Generated paths must match `permissions.actions`.
Only allowed HTTP verbs appear for each entity.

```json
"paths": {
"/api/Author": {
"get": { "summary": "Read all authors" },
"post": { "summary": "Create a new author" }
} // for example, no delete
}
```

#### 6. Proper type formats

The OpenAPI schema must include `format` for date and time types.

| SQL Server Type | OpenAPI Type | OpenAPI Format | Example |
| ---------------- | ------------ | -------------- | ----------------------------------- |
| `date` | string | date | "2025-10-29" |
| `datetime` | string | date-time | "2025-10-29T13:45:30Z" |
| `datetime2` | string | date-time | "2025-10-29T13:45:30.1234567Z" |
| `smalldatetime` | string | date-time | "2025-10-29T13:45:00Z" |
| `datetimeoffset` | string | date-time | "2025-10-29T13:45:30.1234567-07:00" |
| `time` | string | time | "13:45:30.1234567" |

Inizia dagli entry point /openapi, /openapi/anonymous, /openapi/authenticated e /openapi/{custom-role}, quindi esamina la generazione OpenAPI esistente e la gestione della configurazione. Confronta i documenti generati con i requisiti elencati relativi a ruoli, origini dati, campi, strict-body, autorizzazioni e formati di data/ora; il lavoro è completato quando ogni requisito è coperto e verificato dai test pertinenti, anche se nell’issue non ne viene indicato nessuno.

Scritto dal modello di indicizzazione a partire dal testo della issue.