Console behavior with volatile functions and permission inference needs improvements

While debugging a user issue, we discovered the following and thought it should be documented.

## The context
There are multiple ways to create function metadata in the console.
The first is to create the function from the SQL panel and check the option to "track this"
The second is to track an existing function from the database schema in the data tab.
With this second option, the user can choose to track volatile functions as either mutations or queries.
The metadata generated by these methods is different.
Specifically, when the function is tracked on creation, the metadata looks like this:
```
function:
schema: public
name: function_name
```
However, when the function is tracked later, the metadata looks like this:
```yaml
function:
schema: public
name: function_name
configuration:
exposed_as: mutation
```
Or like this if the function was tracked as a query:
```yaml
function:
schema: public
name: function_name
configuration:
exposed_as: query
```

## The problems

#### First problem
The additional configuration object changes the behavior of hasura and the console.
When the configuration object is missing, and the `HASURA_GRAPHQL_INFER_FUNCTION_PERMISSIONS`
env var set to `true`, (which is the default value), hasura will infer permissions based on the select permissions for the table. The console will display those inferred permissions correctly.
If the function is volatile, and thus exposed as a mutation, the console will display the inferred permission based on the select permissions, but the function will not be exposed to any roles (despite the console UI seemingly indicating otherwise).
Except for the console incorrectly displaying permissions, the behavior is in line with our [documentation](https://hasura.io/docs/latest/graphql/core/deployment/graphql-engine-flags/reference/#command-flags):
> When the --infer-function-permissions flag is set to false, a function f, stable, immutable or volatile is only exposed for a role r if there is a permission defined on the function f for the role r, creating a function permission will only be allowed if there is a select permission on the table type. When the --infer-function-permissions flag is set to true or the flag is omitted (defaults to true), the permission of the function is inferred from the select permissions from the target table of the function, only for stable/immutable functions. Volatile functions are not exposed to any of the roles in this case.
(Available for versions > v2.0.0)

This is our first problem.

#### Second problem

The second problem arises when an existing function is tracked from the data tab.
When this happens, the metadata created includes the configuration
object, and permissions will not be inferred, even if the HASURA_GRAPHQL_INFER_FUNCTION_PERMISSIONS
flag is not set, or is set to true. Instead, users are able to explicitly enable permissions for the function.
This feels confusing, and perhaps should be reviewed? I am guessing this behavior is maintained for backwards compatibility reasons, but at the very least the console should not display permission for volatile functions that do not have a configuration object in the metadata, as those will be exposed as mutations for the admin role and not at all for any other (by default).

Start by reviewing the console paths that create or track function metadata and render inferred permissions, comparing metadata with and without configuration.exposed_as. Reproduce both volatile-function cases with HASURA_GRAPHQL_INFER_FUNCTION_PERMISSIONS enabled, then verify that displayed permissions match the function's actual exposure and that tracked-function behavior is consistent.

Written by the indexing model from the issue text.