`az grafana service-account token create --time-to-live` bugs: `10y` yields corrupted expiry (year 1741); omitting the flag gives 1 day

### Describe the bug

`az grafana service-account token create --time-to-live 10y` reports success but creates an already-expired token, with the expiry set to the year **1741**. Separately, omitting `--time-to-live` produces a 1-day token rather than the no-expiry default reported in #8155, and the server-side maximum lifetime that rejects `3650d` is undocumented.

### Related command

```
az grafana service-account token create
```

Also referenced when confirming the behavior:

```
az grafana service-account token list
az grafana service-account create
```

### Errors

Two `--time-to-live` problems observed against an Azure Managed Grafana workspace (UK South) with the `amg` CLI extension:

1. **`--time-to-live 10y` creates a token with a corrupted expiration.** The create call succeeds and returns a key, but `az grafana service-account token list` shows `"expiration": "1741-11-02T16:32:48Z"` with `"hasExpired": true` - the token is born expired (year 1741 suggests an arithmetic/overflow bug in duration parsing for the `y` unit). No error or warning is raised at creation time.

2. **Omitting `--time-to-live` yields a 1-day token**, whereas issue #8155 states the effective default is no expiry. On our instance the created token had exactly 24 hours (`secondsUntilExpiration` ≈ 86400). Either the behavior differs per instance/server config or the documentation and issue are out of date - the actual default should be documented unambiguously.

Additionally, `--time-to-live 3650d` was rejected by the server with `The expiration date input exceeds the limit for service account access tokens expiration date`, but the value of that limit is not documented anywhere we could find, and the `10y` case above bypasses the limit check entirely (it creates the broken token instead of rejecting it).

### Issue script & Debug output

```bash
az grafana service-account create -g -n --service-account test-sa --role Viewer

# Case 1: corrupted expiry
az grafana service-account token create -g -n --service-account test-sa --token t1 --time-to-live 10y
az grafana service-account token list -g -n --service-account test-sa
# -> expiration in the year 1741, hasExpired: true

# Case 2: default is 1 day, not no-expiry
az grafana service-account token create -g -n --service-account test-sa --token t2
az grafana service-account token list -g -n --service-account test-sa
# -> expiration = created + 24h
```

### Expected behavior

1. **`--time-to-live 10y` should either create a token that genuinely expires 10 years out, or be rejected with the same clear error that `3650d` produces.** Silently creating an already-expired token with a year-1741 expiry is the worst outcome: the command reports success and prints a key that fails on first use, with the cause only visible via a separate `token list` call.
2. **The default when `--time-to-live` is omitted should match the documentation.** Whatever the real default is (no expiry per issue #8155, or 1 day as observed here), the CLI help text and the Managed Grafana docs should state it unambiguously, and the CLI should apply it consistently across instances.
3. **The server-side maximum token lifetime should be documented and surfaced.** The rejection message for `3650d` does not say what the limit is, so there is no way to pick a valid long-lived value except by trial and error. Ideally the error names the maximum, and the docs state it alongside the `--time-to-live` unit list.

### Environment Summary

azure-cli 2.87.0
amg extension 3.0.0
Python (Darwin) 3.13.14
Platform macOS (Darwin 25.6.0, arm64)
Install method Homebrew
Azure Managed Grafana region UK South

### Additional context

_No response_

Start with the `az grafana service-account token create`, `token list`, and `service-account create` commands described in the issue, then trace how `--time-to-live` and its omitted default are handled. Reproduce the `10y`, `3650d`, and no-flag cases and inspect the CLI help and Managed Grafana documentation. Done means invalid or excessive lifetimes are handled consistently, the default is explicit, and the reported expiry is correct.

Written by the indexing model from the issue text.