feat(gateway): make provider credential value size limit configurable

The limit is defined as MAX_MAP_VALUE_LEN in crates/openshell-server/src/grpc/mod.rs and used in validation.rs. Start by adding a config field to the TOML schema in config_file.rs and the CLI in cli.rs. Update the validation logic to use the configurable limit instead of the constant. Ensure the Helm chart is updated to expose the setting. Write tests in the relevant test modules to verify the new configurable limit works for provider creation and updates, respecting the per-value boundary.

User Story

As an operator deploying OpenShell for enterprise OAuth-backed providers, I want the maximum size of an individual provider credential value to be configurable at the gateway deployment, so that valid access tokens larger than 8 KiB can be stored without maintaining a custom OpenShell build.

Problem Statement

OpenShell currently hard-codes an 8,192-byte maximum for every value in provider.credentials.

In v0.0.116, MAX_MAP_VALUE_LEN is a compiled constant and is passed directly to provider credential validation. The limit is not exposed through the gateway TOML schema, a CLI flag, an OPENSHELL_* environment variable, or the Helm chart.

This makes the maximum unsuitable for deployment-specific credential formats. OAuth access-token size can vary with identity-provider claims, group membership, scopes, and resource metadata, even when the token is otherwise valid.

Impact / Why This Matters

In a Kubernetes staging deployment using OpenShell v0.0.116, fresh provider creation repeatedly rejected valid Microsoft Graph OAuth access tokens:

• Outlook token: 8510 > 8192 bytes
• Teams token: 8376–8378 > 8192 bytes

The returned gRPC error was:

provider.credentials value exceeds maximum length (8510 > 8192)

A smaller Slack credential was successfully created in the same provisioning trace between the Outlook and Teams failures. This confirms that the limit is applied independently to each credential value, not cumulatively across providers.

No credential contents were logged or needed to diagnose the failure.

Without a supported configuration surface, operators must choose among inadequate workarounds:

• omit the affected provider;
• reduce OAuth scopes or claims, which may remove required permissions and does not guarantee a stable token size;
• patch OpenShell and maintain a private gateway image; or
• wait for a globally raised compiled constant, which still cannot accommodate different deployment policies.

This blocks otherwise valid enterprise OAuth-backed providers and creates avoidable downstream partial-provisioning behavior.

Proposed Design

Expose a documented gateway setting for the maximum byte length of each individual provider.credentials value.

An illustrative configuration could be:

[openshell.gateway]
max_provider_credential_value_bytes = 16384

The Helm chart should expose the same behavior, for example:

server:
  maxProviderCredentialValueBytes: 16384

Desired behavior:

• Preserve 8,192 bytes as the backward-compatible default.
• Apply the setting per credential value; do not sum values within a provider or across providers.
• Scope the setting specifically to provider credential values. Do not implicitly raise limits for environment variables, annotations, provider config, refresh material, or other string maps that currently reuse MAX_MAP_VALUE_LEN.
• Enforce the configured limit consistently on provider creation, credential update, and gateway-managed access-token publication before secret material is handed to the configured credential storage backend.
• Require a gateway restart after changing the setting, consistent with the existing gateway TOML lifecycle.
• Validate the setting at startup and reject unsafe or invalid values against a documented upper bound.
• Keep errors and diagnostics secret-safe: report the actual byte length and configured maximum, never the credential value.

The exact field names and internal representation are implementation choices; the required user-facing outcome is a supported gateway configuration surface that can be rendered by Helm.

Acceptance Criteria

• With no override, the maximum remains 8,192 bytes.
• An operator can configure the per-credential maximum through the gateway configuration used by a Kubernetes/Helm deployment.
• When configured to 16,384 bytes, a credential value of exactly 16,384 bytes is accepted and a value of 16,385 bytes is rejected.
• Two credential values whose combined length exceeds the configured maximum are accepted when each individual value remains within the maximum.
• The configured limit is enforced consistently for provider creation and credential update with built-in encrypted credential storage enabled.
• Gateway-managed credential refresh cannot publish a value that bypasses the configured provider credential limit.
• Limits for unrelated maps remain unchanged.
• Invalid configuration fails startup with a clear, secret-safe error.
• The Helm chart documents and renders the setting into the gateway configuration, and a configuration change rolls/restarts the gateway workload.
• Provider and gateway configuration documentation state that the unit is UTF-8 bytes and the limit is per value.
• Tests cover the default, exact boundary, boundary-plus-one, multiple independent values, create/update parity, and credential-storage-enabled behavior.
• Logs, errors, metrics, and test fixtures never expose credential contents.

Alternatives Considered

Raise the shared constant globally

Increasing MAX_MAP_VALUE_LEN would address the currently observed tokens, but it also changes limits for unrelated string maps and provides no operator control. A provider-credential-specific setting has a smaller blast radius.

Permanently raise the provider limit to 16 KiB

This would solve the present case but token sizes can change as identity-provider claims evolve. Keeping a secure default while allowing an operator-bounded override is more durable.

Reduce OAuth scopes or claims

This may shorten some JWTs, but it can remove required authorization and token size is not a stable contract across users or identity-provider configuration.

Maintain a custom OpenShell gateway image

A source patch works technically, but it requires a private build, image promotion, security maintenance, and repeated rebases for what should be an operator policy.

Use only external credential handles

External credential storage is useful for secret custody, but the gateway still needs a clear and consistently enforced contract for access-token material accepted or published as provider credentials.

Agent Investigation

• Reviewed existing issues using the exact constant, validation field, byte limit, and configurable credential-limit terms; no existing issue covers this request.
• Reviewed the gateway architecture, gateway configuration reference, and provider-management documentation.
• In v0.0.116 grpc/mod.rs, MAX_MAP_VALUE_LEN is hard-coded to 8192.
• Provider validation passes that constant directly for provider.credentials.
• The generic string-map validator compares each value independently.
• The gateway TOML schema has no matching field and denies unknown fields.
• The gateway CLI/environment surface has no matching flag or environment variable.
• The inspected Helm chart has no credential-value limit and no equivalent supported deployment setting.
• #3060 may change Helm-to-TOML configuration plumbing, but the gateway schema still requires an explicit setting for this limit.

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request