values for bit(n) columns are cast to bit(1) and cause a validation error

### Version Information

Server Version: 2.6.1
PostgreSQL Version: 12.10

### Environment

OSS

A table with a column of type `bit(n)` with `n > 1` is present.

### What is the expected behaviour?

The `bit(n)` field can be written (insert / update) via GraphQL.

### Keywords
`bit`, `bitmask`, `length`, `bit string length 1 does not match type`

### What is the current behaviour?

Whenever the `bit(n)` field is set to a new or its current value through a GraphQL insert or update, the request fails with the following error (example for `n = 4`):

`bit string length 1 does not match type bit(4)`

### How to reproduce the issue?

1. Create a table with a column of type `bit(4)`
2. Insert a new entry through GraphQL, setting the `bit(4)` field to `1111`
3. The request fails with a validation error `bit string length 1 does not match type bit(4)`. The validation error occurrs with every value, not only with `1111`.

### Screenshots or Screencast

### Please provide any traces or logs that could help here.

```
hasura-api-graphql-engine-1 | {"type":"query-log","timestamp":"2022-05-06T19:07:23.370+0000","level":"info","detail":{"kind":"database","request_id":"b1229614-1d72-4229-916d-027883e26bdf","generated_sql":null,"query":{"operationName":"MyMutation","query":"mutation MyMutation {\n insert_demo_one(object: {bitmask: \"1111\"}) {\n bitmask\n id\n }\n}\n"}}}
hasura-api-postgres-1 | 2022-05-06 19:07:23.377 UTC [547] ERROR: bit string length 1 does not match type bit(4)
hasura-api-postgres-1 | 2022-05-06 19:07:23.377 UTC [547] STATEMENT: WITH "demo__mutation_result_alias" AS (INSERT INTO "public"."demo" ( "bitmask" ) VALUES (('1111')::bit) RETURNING * , ('true')::boolean AS "check__constraint"), "demo__all_columns_alias" AS (SELECT "bitmask" , "id" FROM "demo__mutation_result_alias" ) SELECT (SELECT coalesce((json_agg("root" )->0), 'null' ) AS "root" FROM (SELECT row_to_json((SELECT "_1_e" FROM (SELECT "_0_root.base"."bitmask" AS "bitmask", "_0_root.base"."id" AS "id" ) AS "_1_e" ) ) AS "root" FROM (SELECT * FROM "demo__all_columns_alias" WHERE ('true') ) AS "_0_root.base" ) AS "_2_root" ) , (SELECT coalesce(bool_and("check__constraint" ), 'true' ) FROM "demo__mutation_result_alias" )
hasura-api-graphql-engine-1 | {"type":"http-log","timestamp":"2022-05-06T19:07:23.370+0000","level":"error","detail":{"operation":{"user_vars":{"x-hasura-role":"admin"},"error":{"path":"$.selectionSet.insert_demo_one.args.object","error":"bit string length 1 does not match type bit(4)","code":"data-exception"},"request_id":"b1229614-1d72-4229-916d-027883e26bdf","response_size":134,"query":{"variables":null,"operationName":"MyMutation","query":"mutation MyMutation {\n insert_demo_one(object: {bitmask: \"1111\"}) {\n bitmask\n id\n }\n}\n"},"request_mode":"error"},"request_id":"b1229614-1d72-4229-916d-027883e26bdf","http_info":{"status":200,"http_version":"HTTP/1.1","url":"/v1/graphql","ip":"172.22.0.1","method":"POST","content_encoding":null}}}
```

### Any possible solutions?

The resulting `INSERT` statement should be (for `n = 4`)
`INSERT INTO "public"."demo" ( "bitmask" ) VALUES (('1111')::bit(4))`
instead of
`INSERT INTO "public"."demo" ( "bitmask" ) VALUES (('1111')::bit)` (see logs)

### Can you identify the location in the source code where the problem exists?

No

### If the bug is confirmed, would you be willing to submit a PR?

Yes, if you help me with where to start looking in the code :)

Start with the generated SQL in the issue log and trace how GraphQL insert values for PostgreSQL bit columns are cast. Compare the shown `::bit` cast with the requested `::bit(4)` cast; done means inserts and updates for `bit(n)` columns accept values of the column's declared length.

Written by the indexing model from the issue text.