monitor: honor the address argument in the /transport_dbg route

[Jordanplus]

Problem

The monitor's /transport_dbg/<int>/<str> REST route parses an address from the URL but never uses it. The TLM payload address is hardcoded to 0, so every debug read returns the word at offset 0 of the target socket, regardless of the requested address:

qbox/systemc-components/monitor/src/monitor.cc

Lines 358 to 371 in c00e7f7

	CROW_ROUTE(m_app, "/transport_dbg/<int>/<str>")
	([&](uint64 addr, std::string name) {
	crow::json::wvalue r;
	auto sc_obj = gs::find_sc_obj(nullptr, name, true);
	auto exp = dynamic_cast<tlm::tlm_base_target_socket_b<>*>(sc_obj);
	if (!exp) {
	r["error"] = "Object not a tlm base target socket";
	return r;
	}
	uint32_t data;
	tlm::tlm_generic_payload txn;
	txn.set_command(tlm::TLM_READ_COMMAND);
	txn.set_address(0);

This contradicts the documented behavior ("Read 4 bytes at address <decimal_addr>"):

qbox/docs/monitor-debugging-guide.md

Lines 78 to 90 in c00e7f7

	## 4. Reading Memory via Debug Transport
	```bash
	# Read 4 bytes at address <decimal_addr> via <socket_name>
	curl -s http://localhost:18088/transport_dbg/<addr>/<socket>
	```
	The address is in **decimal** and the socket is the full SystemC
	hierarchical name of a TLM target socket. The read goes through
	TLM `transport_dbg`, which is non-intrusive (does not advance
	simulation time).
	### Example — Reading through the platform router

Root cause

txn.set_address(0); at monitor.cc#L371 — the addr lambda parameter is accepted but unused.

Fix

One line: use the parsed addr as the transaction address.

The two other set_address(0) calls in this file (the object-hierarchy JSON preview helpers, L162 and L200) are intentional first-word previews with no address parameter available, and are left untouched.

How verified

Verified on a v7.3.0-based aarch64 platform by reading device registers at non-zero offsets through the platform router via /transport_dbg:

• Before the fix: reads at +0x004 / +0x008 / +0x00C inside a device's register window all returned the register at offset 0.
• After the fix: each read returns the correct register value at the requested offset.

Note: this likely also explains the "GIC debug transport" limitation recorded in the debugging guide (docs/monitor-debugging-guide.md#L98-L104 and #L268-L270) — the offset was being dropped by the monitor route itself, not by the GIC model. Happy to update those doc paragraphs in this PR or a follow-up, as maintainers prefer.