docs: add Agent-friendly entry index and source-derived API specs

[abn2357]

Summary

• Add docs/llms.txt as an Agent entry index linking the API references and node-operation pages (served at /llms.txt).
• Add source-derived API specs: OpenAPI (docs/api/openapi.yaml), OpenRPC (docs/api/openrpc.json), and per-endpoint HTTP / JSON-RPC spec files under docs/api/specs/, generated by scripts/generate_api_specs.py.

Spec quality assurance

The API specs were validated through multiple rounds of self-audit by the generating model and cross-audited by other models.

Unrelated fixes bundled in

The following two items are not part of the Agent-friendly docs theme. They address two optimization items surfaced by the routine AI audit report and are included here for convenience:

• Declare documentation-en as the authoritative source on the home page, with this Chinese repository as the translation that follows it.
• Add an SR-setup safety note: chmod 600 the config, never commit a config file with a real private key, and prefer keystore.

Test plan

• mkdocs build succeeds with the new pages and mkdocs.yml nav entry.
• /llms.txt resolves and its links point to valid pages.
• Generated OpenAPI / OpenRPC specs parse without errors.

[vivian1912]

The direction is valuable — generating machine-readable specs from java-tron source ground truth is the right idea. But I'd recommend reworking the PR before merging, primarily around where these artifacts live and how strict the schemas should be.

1. Generated artifacts should live alongside the source they describe, not in the docs repo
   The ~21k-line / 130+-file payload here is almost entirely auto-generated. The current arrangement may create a coupling problem.
   Where things should ideally live:

• java-tron (or a dedicated tron-api-specs): api/openapi.yaml, api/openrpc.json, api/specs/*, scripts/generate_api_specs.py — versioned alongside the code they describe; regenerated and validated in CI
• documentation-zh (here): interface-definitions.md + llms.txt only — short pointer pages linking to the specs in their canonical home
  Reference: ethereum/execution-apis does exactly this — JSON-RPC specs in their own repo, narrative docs link to them.

2. Schema strictness is too loose for practical SDK generation

• Required fields aren't declared. createaccount.yaml lists owner_address and account_address in properties but doesn't include them in a required: [...] array — so generated clients will treat every field as optional. Reading the actuator validation in CreateAccountActuator.java#L91-94, owner_address is clearly required (validated as a non-null TRON address). The script could derive required lists from the actuator validation rules.
• Enum types are flattened to object. In freezebalancev2.yaml, resource is typed as object with additionalProperties: true, but the underlying field is a ResourceCode enum (BANDWIDTH | ENERGY | TRON_POWER). Other proto enum fields in the schema get the same treatment. Generated SDKs lose type safety on these.
• additionalProperties: true is the default on nearly every object schema. This effectively says "any unknown field is acceptable" — useful for forward-compat, but combined with (a) and (b) it means consumers end up with Map<String, Any> for most request and response payloads.
• Error response shape isn't modeled. Only HTTP 200 and 404 are described. The actual TRON HTTP error path is HTTP 200 with {"Error": " : "} in the body — see Util.java (jsonObject.put("Error", e.getClass() + " : " + e.getMessage())). Without this modeled as an alternative schema (e.g., via oneOf), generated SDKs deserialize both 200 responses into the "success" type with all fields nullable. Clients have to fall back to manual string-checks for the Error key, defeating the type-safety motivation for using OpenAPI.