Fix system contracts doc: sync with java-tron proto

[abn2357]

Summary

Follows the English-side PR tronprotocol/documentation-en#601 to bring the Chinese docs/mechanism-algorithm/system-contracts.md back in sync, and additionally corrects proto-field discrepancies that were missed by the English PR after cross-checking against the java-tron source (protocol/src/main/protos/core/contract/*.proto).

Changes aligned with the English PR (commit 3abcfd7)

• Added a top-level ContractType overview table for easy cross-referencing; replaced the duplicated ContractType table in multi-signatures.md with an anchor link to this overview.
• Removed the "（已废弃）" prefix from the FreezeBalanceContract heading since its disabled status is already reflected in the new ContractType overview table.
• Reordered UpdateEnergyLimitContract, ClearABIContract, UpdateBrokerageContract, and added a new AccountPermissionUpdateContract section, all placed before ShieldedTransferContract.
• Added MarketSellAssetContract and MarketCancelOrderContract after ShieldedTransferContract.
• Added Stake 2.0's CancelAllUnfreezeV2Contract at the end.
• Clarified AccountPermissionUpdateContract field semantics: witness is required only for SRs and must be empty for non-SRs; actives is capped at 8.

Additional fixes from source-code cross-check (commit 9b2d476)

• UnfreezeBalanceContract.receiver_address: field number corrected from 13 to 15.
• AssetIssueContract: added missing int32 precision = 7; and string id = 41; fields, with matching field descriptions.
• AssetIssueContract.order: updated the stale inline comment from // the order of tokens of the same name to // useless (the field has no business effect in the current source).
• DelegateResourceContract: added the missing int64 lock_period = 6; field with a description covering its semantics and the MAX_DELEGATE_LOCK_PERIOD proposal gating; corrected the lock field description (the original "lock for 3 days" is no longer accurate).

Terminology and field-description polish (commit f2becc9)

• Per-contract owner_address descriptions. Replaced the catch-all "合约持有人地址" with contract-specific semantics, cross-checked against the corresponding *Actuator.validate() in java-tron. For example: AssetIssueContract.owner_address → "发行 TRC-10 token 的账户地址"; UnfreezeAssetContract.owner_address → "token 发行方账户地址"; UpdateSettingContract / UpdateEnergyLimitContract / ClearABIContract → "智能合约部署者账户地址" (validated by the Arrays.equals(ownerAddress, deployedContractOwnerAddress) check in each actuator).
• Witness terminology. Renamed headings and field descriptions that used "超级节点候选人" to "Witness" (e.g. "创建 Witness", "更新 Witness URL", "投票 Witness") to match the proto type name and the rest of the doc.
• TRC-10 spelling. Standardized TRC10 → TRC-10 across the ContractType table and prose, and added missing spaces around TRC-10 in bullet descriptions.
• Token vocabulary. Replaced legacy 通证 / 代币 with token and lowercased it in prose; proto field names and code blocks (token_id, call_token_value, first_token_id, ...) are intentionally left as-is to match the source.
• AssetIssueContract heading. Changed "## 发布 TRC-10 …" to "## 发行 TRC-10 token AssetIssueContract" to align with the contract's actual semantics (AssetIssueContract = issue, not publish).

Test plan

• mkdocs build --strict passes
• The ./system-contracts.md#contracttype anchor resolves correctly from multi-signatures.md
• All revised fields match the current java-tron master proto definitions
• Each per-contract owner_address description was cross-checked against the corresponding *Actuator.validate() in java-tron

[vivian1912]

Note: the owner_address description ("合约持有人地址") is a long-standing ambiguity in this doc. A more precise definition: owner_address is the address of the account whose pending V2 unfreeze operations are to be cancelled — i.e. the resource-owning account, not necessarily the transaction signer. In a multi-sig scenario, the actual signer could be a delegated account that holds the required permission on behalf of the owner. This applies consistently across all system contracts. No need to block this PR — suggest to address it in a follow-up cleanup PR.

[abn2357]

I really agree with your statement. This translation is both outdated and inaccurate. How about globally translating it as "Transaction initiator address", which applies to all transaction types?

[vivian1912]

"Transaction initiator address" might not be accurate in a multi-sig scenario. I haven't found a single unified description that works cleanly across all system contracts yet. Looking forward to more good ideas. Now I'm leaning toward per-contract descriptions, e.g. FreezeBalanceV2Contract — "The address of the account that stakes TRX", CreateSmartContractContract — "The address of the account that deploys the contract", and so on.

[abn2357]

The owner address doesn't seem to have anything to do with multi-signature. It's like an SR—he can grant witness permissions to another account, but the block owner is still himself—only the signature changes.

[vivian1912]

You're right that owner_address itself is independent of multi-sig — it always identifies the account the operation belongs to, regardless of who signs. The concern is specifically with the term "initiator": in a multi-sig scenario, the actual initiator (signer) is the delegated account, not the owner. So "Transaction initiator address" could be misread as referring to the signer rather than the owner. That's the ambiguity we're trying to avoid.

[abn2357]

Yes, we need to find a more accurate description — preferably a unified one.

[abn2357]

I have written a separate definition of owner_address for each contract type as you suggested. Also, I drop subjects from ContractType overview table to avoid permission ambiguity. Please review it again, Thx. Detailed information starts from this commit.